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Summary 


Every year, around 2 million sheep are released onto open field pastures in Norway. 

During the grazing period, which lasts 16 weeks for sheep and goats, the sheep roam freely and have 

the opportunity to seek out the best pastures to graze on. This period is not without danger for 

the sheep. Figures from 2019 show that 6.5% of the lambs and 3.2% of the sheep that were let out 

to pasture that year did not return when the sheep were shorn in the autumn. There are many 

reasons why sheep do not survive the grazing period, such as disease, environmental factors or 

predators feeding on the stock. All farmers who keep sheep on pasture are therefore required to 

monitor their animals while they are on open pasture. Farmers who keep animals on open pasture 

are entitled to state compensation for sheep lost to protected game during the grazing 

period. The loss must be documented when applying for compensation to the Norwegian Environment Agency. 


Today, field pasture inspections are largely carried out using pen and paper, and manual solutions 
such as spreadsheets or binders are used to collect and store the collected data. The collected 
data has no set structure and there is no standardized way of generating reports to document 

the grazing season. In order to simplify the process of recording observations on inspection trips, 
structure the collected data, improve the flow of information in the grazing team and streamline the 
documentation process, a system consisting of a mobile application and a web 

application with a common backend service was developed. This report describes the design, 
development, testing and evaluation of this system and the processes that have been carried 

out in that context. 


On the basis of initial conversations with domain expert Svein-Olaf Hvasshovd, requirement 
specifications and targets were determined at the start of the project. Based on this, conceptual 
models and flow charts were developed which formed the basis for the design of the first version 

of the system. The system was then user tested in several rounds and the users' feedback was 
incorporated into the solution. During the development period, consideration was largely given to the 
functionality desired by the users and the defined target group, when choosing technology and 
developing system components. The development period resulted in a complete solution that 
received good feedback from users during final user tests, and achieved good results 

during comparison tests with current methods. 


The final evaluations of the system show that the system works more efficiently than current 
methods. The system offers complementary and sufficient information to the users, fulfills the 
users' needs very well and meets the requirements and goals that were defined at the start of the 
project. 
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Abstract 


Every year about 2 million sheep are let out to graze in outfield pastures in Norway. 

During the grazing period which lasts for 16 weeks for sheep and goats, the animals roam 

freely and are free to seek out the best grazing areas. This period is however dangerous for 

the animals, and numbers from 2019 suggest that 6.5% of lambs and 3.2% of sheep that are 

let out to graze, never return. There are many reasons for sheep not surviving the grazing season, 
such as illness, environmental factors and predators. 

Because of this, all farmers who keep sheep in outfield pastures are required to follow up on their 
animals while they are out grazing. These farmers are entitled to compensation from the government 
should their livestock be lost to protected predators during the grazing period. These losses 

must be documented when applying for compensation from the Norwegian Environment Agency. 


Today the registration of events during supervision of sheep is mostly done using pen and paper, 
and manual methods like spreadsheets or folders are used for collecting and storing the gathered 
data. The data collected has no set structure and there is no standardized way of generating 
reports of the completed grazing season for documentation purposes. To simplify the 

process of registering observations while performing supervision trips, structure the gathered 
data, improve the flow of information in grazing groups and make the documentation 

process more effective, a system consisting of a mobile application and a webapplication with a 
common backend as a service solution was developed. This report describes the design, 
development, testing and evaluation of this system, and the processes accompanying it. 


Based on the initial conversations with the domain expert, system requirements and 

goals were developed at the start of the project period. On the basis of this, conceptual 

models and flow diagrams were developed which laid the foundation for the design of the first 
iteration of the system. The system was then run through several usability tests and the user's points 
of feedback were implemented. During the development period users wishes for functionality as 

well as the defined user group for the system were taken into consideration when selecting 
technology and development of system components. The development period resulted in a fully 
functioning system that received good feedback from users during the final usability tests and 
achieved good results during the comparative tests with the methods used today. 


The final evaluation of the system shows that the system works more effectively than the methods 
used today, offers extensive and sufficient information to the users, fulfills user needs very well and 
achieves the requirements and goals that were defined at the start of the project. 


we 
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Preface 


Through this project, a system has been developed to simplify the supervision of sheep on open 
pasture, and to make it faster and easier to document the completed grazing season. The system 
consists of a mobile application and a web application where the mobile application is centered 
around information registration and the web application offers a structured overview of all registered 
data in addition to opportunities to generate reports. 


If anyone wants to test the system, the mobile application has been launched on both the Google play 
store and the Apple app store for internal testing. 


To test through Google play send an email to: contact.weluQgmail.com. 

To test via the app store follow the link: https://testflight.apple.com/join/Ubg2STUR 
The web application is available at: https://beiteweb.herokuapp.com 

Test user for the system is: beitemaster.testØgmail.com 


Password: tester123 


Please note that data uploaded to the website may be available to other members of the groups you 
participate in. However, it is optional to upload information from the mobile application and 
all data recorded will be private on the phone until this is done. 


We would like to thank our supervisor and domain expert Svein Olaf Hvasshovd in addition to everyone 
who participated as user testers of the system and thus contributed to a large extent to the design of 
the final solution. 
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1 Introduction 
1.1 Actors 


1.1.1 Development Team 

Throughout the assignment, reference will be made to the Team. The team consists of two students at 
study program Computer Technology at NTNU. Both students have been admitted to the 

software systems course of study. 


1.1.2 Internal supervisor and product owner 

The supervisor for this project at NTNU has been Svein-Olaf Hvasshovd, professor at the Department of 
Computer Technology and Informatics. Professor Hvasshovd has in-depth knowledge of the domain through 
long experience of assisting farmers who run sheep farms on open pastures, in addition to long 

experience of supervising tasks within the same field. 

He will therefore be the main source of the task's domain knowledge with respect to the farmers' 
experiences, problems and challenges as of today. 


On the basis that this project has been carried out as an independent project, Professor Hvasshovd 
will also hold the role of product owner for the system. 


1.2 Motivation 

Every year, around 2 million sheep are let out onto open field pastures in Norway (Mattilsynet, 2020). During 
the grazing period, which lasts 16 weeks for sheep and goats (Norwegian Farmers Union), the sheep roam 
freely and have the opportunity to seek out the best grazing areas to graze on. This period is not without 
danger for the sheep. Figures from 2019 show that 6.5% of the lambs and 3.2% of the sheep that were let 
out to pasture that year did not return when the sheep were slaughtered in the autumn (Mattilsynet, 2020). 
There are many reasons why sheep do not survive the grazing period, such as disease, 

environmental factors or predators feeding on the stock (Dyrebekstelltningen Norway). All farmers who keep 
sheep on pasture are required to follow up on their animals, while they are on open pasture (Forskrift om 
welferd for småfe, 2005). 

Farmers who keep animals on open pasture are entitled to state compensation for sheep lost to protected 
wild game over the grazing period (Regulation on wild game compensation for domestic animals, 2014). 
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To be eligible for compensation, the farmer must submit an application to the Norwegian Environment Agency 
after the end of the grazing season where he/she documents his herd and the losses they have had during the 
season (Environmental Directorate, 2021a). The Farmers' Association recommends making extensive use of 
appendices in this application, in order to shed light on aspects of the grazing season that are not directly 
documented through the Norwegian Environment Agency's application form (Norwegian Farmers' Association, 
2020). This includes matters such as observations of wild game, documentation of losses, documentation that 
supervision of the sheep has been carried out and how the supervision has been carried out. There is no 
standard for what such an attachment looks like and the vast majority of farmers and grazing teams currently use 
paper and pencil to register sheep when inspections are carried out. 


The purpose of this thesis is to present the development, testing and evaluation of a new system for registering 
supervision of sheep on pasture, with the main aim of simplifying the process for supervisors who register their 
trips, centralizing the flow of information in grazing teams and making it easier to produce reports based on during 
the grazing season 

events. 


1.3 Target groups 


- Farmers who run sheep farms and have sheep on open pasture 
- Supervisors who support farmers by going on inspection rounds in grazing areas 
- Leaders in grazing teams 


1.3.1 Number of potential users 
Based on the defined target groups for the project, it can be roughly estimated how many potential users the 
application has. 


Number of farms with sheep on open pasture 


According to figures from Statistics Norway, in 2020, there were 17,931 agricultural holdings with livestock on outdoor pastures 
(SSB, 2021). Livestock here is not limited to sheep, but includes cattle, goats, horses 

and domestic reindeer. The Norwegian Farmers' Association states that in 2021, according to the Directorate 

of Agriculture's data, there were approximately 12,000 agricultural enterprises that applied for production 

subsidies for sheep released on open pasture (Larsen, 2021). Based on these figures, it can be estimated that the 
number of farms that have sheep on open pasture is somewhere between 12,000 and 18,000. 


Number of grazing teams with sheep on open pasture 


According to the Norwegian Farmers' Association, there are no concrete figures on how many pastures exist in 
Norway as of today (Larsen, 2021), but according to the Norwegian Institute for Bioeconomy 

(NIBIO) approx. 74% of sheep on open pasture in Norway as of 2021 are organized in organized grazing 
(NIBIO, 2021). 


Estimation of user group 


Based on conversations with Professor Svein-Olaf Hvasshovd, there is reason to believe 

that each farm has at least one farmer or supervisor attached to it, in many cases more. For this part of the 
estimation, it has been assumed that there are between one and three supervisors per farm. Based on the figures 
presented above and this information, it is thus estimated that the user group for the system developed in 
connection with this task is somewhere between 12,000 and 54,000 people. 
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1.4 Objectives of the project 


The overall goal of the project is the development of a system that, with the help of å mobile application 
and a web application, simplifies the process of supervising sheep on open pasture, centralizes 

the grazing team's data flow and makes it easier to produce reports for the Norwegian Environment Agency 
at the end of the grazing season. 


The subordinate concrete targets described in this section are categorized as impact targets and result 
targets. 


1.4.1 Performance measures 


- Easier and faster to note observations during an inspection tour 

- Easier to register completed inspection visits 

- Simplify and streamline the report generation process for submission to the Norwegian 
Environment Agency 

- Easier to keep track of the grazing team's common data and their own sheep and loss figures 


The main aim of the system is to simplify tne documentation of the grazing season's events by offering åa 
structured and efficient way to register inspection trips, in addition to simplifying the process around the 
generation of reports. By centralizing the information in the grazing team so that everyone has access 
to the same data throughout the season without additional distribution work, the flow of data in 

the grazing team will improve and each farmer will have control over his data at all times. 


Throughout the project, it has been a focus area to carry out user tests at all iterations of the 
product to ensure as user-friendly a result as possible. 


1.4.2 Performance measures 


- The mobile application's functionality according to the table below 

- The web application's functionality according to the table below 

- The system is available to everyone in the target group 

- The system satisfies the current requirements of the GDPR in accordance with current legislation 


The project has aimed to result in a functional system that is easy to use for all users in the target group. 
The system was to include a registration solution for inspection trips, an overview of pastures 

and data and report generation for compensation applications. The tables below 

present the performance targets for mobile and the web application respectively, grouped 

based on which functionality they belong to. 
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Mobile application 
Functionality 


Create profile - Å user must be able to create a profile to 
ds 
Log in - Å user with åa profile must be able to 
access the system with your email and 
password 
Profile - Å user must be able to delete their profile 
- Å user must be able to change their 
profile information 
Feed - Å user must be able to see the most recent 
trips that have been completed 
- Å user must be able to access 
older trips and see details about the trip 


Grazing groups - Å user must be able to create a new grazing 
group 
- Å user must be able to create farms in 
the grazing group 
- Å user must be able to add members 
to the group 


- Å user must be able to accept an 


invitation to a grazing group 
- Å user must be able to access 


their grazing groups and see trips 
completed in the group 
- Å user must be able to manage the group if 


the user is an administrator 


Supervisory tour - Å user must be able to start a new 


supervision tour 
- Å user must be able to download å map section 


for use without the internet 

- Å user must be able to register herds as 
appropriate 
level of detail based on how much 
the user sees 

- Å user must be able to register events 
on å supervision trip like this 


like the sight of predators 
- Å user must be able to see one 


overview of the trip when the trip has 
been completed 
Table 1.1: Outcome measures for the mobile application 
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Web application 


| Functionality | FK] 


Create profile - Å user must be able to create a profile to use 
om | nomen — 
Log in - Å user with åa profile must be able to access the system with 


Profile - Å user must be able to delete their profile 
- Å user must be able to change their profile information 
See inspection tour - Å user must be able to see details of the trip after completing the trip 


- Å user must be able to see the grazing quality in the grazing area 
the map 


Generate report - Å user must be able to generate reports based on the grazing 
season in å standardized format 


Table 1.2: Outcome measures for the web application 


1.5 Brief product description 


The system that has been developed will offer supervisors, farmers and grazing team managers a 

simpler and more efficient way to record events and observations during supervision trips on 

open field grazing. The system will also improve the possibility of continuous access to data about the farm's 
sheep, losses and other observed events throughout the season, in addition to keeping a log of when 

trips have been carried out and who has carried out the trips. At the end of the season, farmers will be able to 
access a website to generate a seasonal report in a standardized format, which can be attached to any 
applications for compensation for losses to the Norwegian Environment Agency. 


Oppdalsgruppa 
I 28.5.2022 19:01 
Hans Karlser 


:  Hedmarksgjengen 
3.5 22 19:04 


Oppdalsgruppa 
nnå Fredriksen 


et Oppdalsgruppa 


1 
Fredrik 


:e06e0e]! 


DDD 


Figure 1.1: Image of the web and the mobile application 
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2 Research methodology 


2.1 Objectives and problem 


The aim of the project is to develop å system that can streamline the recording of data on inspection 
trips, centralize the flow of data in the grazing team as well as streamlining and structuring reports 
from the grazing season. Based on this goal formulation, four research questions have 

been drawn up to evaluate the system's goal achievement and effectiveness: 


Q1: How much more efficient is it to record observations using Beitemaster 
as opposed to with current methods? 


F2: How precise, detailed and sufficient is the information recorded using 
Grazing masts compared to current methods? 


Q3: How much more efficient is it to produce reports using Beitemaster i 
contrary to traditional methods? 


F4: How well does Beitemaster meet the users' needs when it comes to monitoring sheep on open 
pasture? 


The answers to the research questions above will help to evaluate the system's effectiveness and 
goal achievement and lay the foundation for further work with the system and mapping of 
improvement potential in the area. 


2.2 Method 


The project has been carried out in several phases where the first phase has consisted of 

gathering information about the current situation. This phase was critical to enable the research 
questions to be answered and to lay the groundwork for preparing requirements specifications 

and design specifications for the system. The information-gathering phase mainly consisted of 
interviews with people with knowledge of the current practice of sheep on open pasture, investigations 
of existing solutions, investigations of regulations, and standards and recommendations in relation 

to the replacement of lost sheep. Details of the information gathering and findings made in this 

phase will be further presented in the section "Background". 


Based on the experiences, descriptions and information obtained in this first phase 

the goal and problem for the project were determined. It was theorized that the development of 

a system to structure the way data is collected, stored and generated could solve part of the 
challenges identified with current solutions. Figure 2.1 shows an overview of the chosen method 
and strategy for the project in addition to the chosen data generation method. The strategy 
adopted was "Design and creation" where the development of the system was the main focus of 
the project. The background for choosing this strategy was that, as the project would result in å 
new product that does not exist as of today, the system itself, in addition to answering the research 
questions 
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promote knowledge in the area and be able to lay the foundations for further development (Oates, 
2006). 


Strategies Data generation 


. methods 
Experiences 
er Survey 
and motivation | å 
Å — nterview: 
Research Tann NE 
ss n 
question(s) 3 Data 


Design and 


å analysis 
creation 
Fv usually 
GF E > Quantitative 
| Literature | lil [ I Observation 
| review | Experiment | 
==="<Xo=2| | 
34 ==r=="=" often 
, : an > 
—— 
Conceptual : 


p IN - 
framework | Case study | Question- : 
===" ————=—=" naires | Qualitative 
Action | annet 
research | 


Ethnography | 


Figure 2.1: Illustration of research method used in the project (Oates, 2006) 


Throughout the development phase, the system was designed, tested and implemented in 
several rounds with a focus on feedback from users. Through the tests that were carried out, both 
observations and structured interviews were used for data collection. 


User testing was first carried out after designing a "proof of concept" using a paper prototype, where 
the users could test the general functionality and structure of the application. 


The next user test was carried out with an interactive prototype created using Figma 
(Figma) where the users' feedback from the previous test had been emphasized. 

The main focus of this test was the user's experience of structure, functionality, and general 
experience of design and flow in the application. 


Based on the users' further feedback on the Figma prototype, the development of the application 
was started. The final and complete solution was user tested at the end of the project period and the 
collected data laid the basis for answering the defined research questions. Figure 2.2 shows 

the project's development phases and completed user tests. The user tests are described 

in greater detail in the section 


"User testing of design" and the evaluation of the system are elaborated in more detail in 
section "Results". 


Proof of concept p Test | Figma prototype > Test Applikasjon p, Test 


Figure 2.2: Test sequence for the project 
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3 Background 


3.1 Current situation 


When sheep are released to pasture at the start of the grazing season, farmers are responsible for monitoring 
their animals regularly and documenting the supervision they do. Historically, the supervision and follow-up of 
sheep on open pastures has been carried out by shepherds with special expertise in this particular field. 

Such herding practices have largely been phased out in Norway against the background of increasing 
demands for the efficiency of agriculture, stricter working environment requirements and å low 

predatory game population (Hind, 2018). Despite the fact that the herders have all but disappeared, there 

are requirements laid down in the legislation for follow-up of the animals on pasture to ensure the 

best possible animal welfare and the fewest possible losses throughout the season. There can be 

many reasons for the loss of sheep on open pasture, but the most common causes are disease, accidents 
and predators (Directorate of Agriculture). 


According to the law, it is the animal keeper's responsibility to ensure as well as possible that the grazing 
animals are protected from predators and unnecessary stress during the grazing period 

(Directorate of Agriculture). Today, there are several damage prevention measures that can be used, 
preferably in combination, to protect your animals as best as possible against loss to predators. 

Predator fences that enclose grazing areas to keep predators out, or radio tracking of ewes to monitor activity 
and position are such options (Hind, 2018). Unfortunately, such measures often entail large expenses for the 
farmers and even though public support schemes for partial financing have been established, supervision and 
maintenance are still required (Hind, 2018). Despite preventive measures, farmers lose sheep to 

predation every year, and the worst-hit herds can in the worst case be halved, which in the extreme could 
mean the end of further operations (Hind, 2018). 


As the Storting has decided that there must be a number of game of prey in Norwegian nature and that the 
population must be of a certain size, compensation schemes have been established for Norwegian farmers who 
lose sheep to game of prey (Directorate of Agriculture). This means that the farmer can receive full 
compensation for the animals that have been felled by protected game, which makes documentation of the 
grazing period very important. 


3.1.1 Supervision and compensation for lost sheep 


Farmers can be entitled to compensation for their grazing animals, if they can be shown to have been taken 
by wild game during the period they are grazing. Nevertheless, there are certain criteria a farmer must 
combply with if he/she is to be entitled to compensation in addition to having to submit his claim for 
compensation by 1 November each calendar year. Some of the criteria that must be met in order to 

be entitled to such compensation are (Regulations on predatory compensation for livestock, 2014): 


- "The animal owner has acted carefully and has done what can reasonably be expected to avert or reduce 
loss, assessed in relation to the values at stake and the risk involved." 


- "The animal husbandry in the herd is in accordance with Act 19 June 2009 no. 97 on animal 
welfare and regulations to the act." 
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- "Pet owners have helped to detect losses as early as possible. As soon as a case of loss or damage is discovered, 
notification must be given to the Norwegian Nature Inspectorate for an assessment of the cause. 


- "The animal owner has provided correct and necessary information to substantiate the claim for compensation. This 
involves herd data at individual level, including data on lost and injured animals. If the animal owner has 
given complete herd data to the sheep control, and has consented to the use of herd data from this, this 


requirement is considered to have been met" 


One of the requirements that must be met to ensure adequate animal welfare during the grazing period is periodic 
supervision of the animals, specified at least once a week (Regulations on welfare for small animals, 2005). In order 

to cover this requirement adequately, it is common for several farms to join together and form grazing teams, where 
they then roll on who goes on inspection rounds and looks after the sheep. The supervisor goes for a walk 

in å selected part of the grazing area, notes the number of sheep seen, their condition, whether the number of 

lambs in the flock matches the markings on the ewes and which farm the sheep belong to. If a farmer suspects that 
animals have been taken by wild game, any tracks and other findings must be documented, the others in the 

group must be informed and the Norwegian Environment Agency (SNO), which is the Norwegian Environment Agency's 
field agency, must be notified (Norwegian Farming Association, 2020). 


When losses are suspected, it is important that the discovery of any bodies or other parts of dead animals is carefully 
recorded. This includes where discoveries were made, what condition the finds are in, environmental factors at the site, 
images of the discovery area and other metadata such as time and date (Norges Bondelag, 2020). When SNO is 
notified of the discovery of dead animals suspected to have been killed by wild game, they will carry out an evaluation 
of the findings. Either by sending out a delegation for further investigations or by contacting the farmer directly 

to register information. They will then conclude on the probability that the animal has been killed by wild game and thus 
whether compensation is justified according to the law (Environment Directorate). In most cases, you will not find the 
remains of dead sheep if wild game is responsible for their death (Norges Bondelag, 2020). In cases where no findings 
are available, SNO will therefore conclude on the basis of probability when fixed criteria are met (Regulation on 
rovilterstatning for domestic animals, 2014). 


If the farmer wishes to apply for compensation on the basis of lost animals to protected wild game, an application 

for this must be sent to the Norwegian Environment Agency (Environment Directorate, 2021a). 

The application process takes place by submitting a form where the farmer's herd, grazing area and their losses 

during the grazing season are documented. The Norwegian Farmers' Association recommends that appendices 

are used frequently in the application, for documentation of aspects that can contribute to åa more accurate picture of the 
farmer's situation (Norwegian Farmers' Association, 2020). This includes, among other things, documentation 

of: 


- Observations of protected wild game in the grazing area. 

- Reports from SNO. 

- Private documentation of losses, should SNO's report be fruitless. 
- How hours of supervision are calculated. 

- How the supervision has been carried out. 


Furthermore, the Norwegian Farmers' Association recommends that all grazing teams document their completed 
inspection trips in order to be able to prove that inspections have been carried out in accordance with the law and to 
do better in a compensation case (Norwegian Farmers' Association, 2020). 
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3.1.2 Extent of damage 

In 2021, compensation was paid for 16,864 sheep lost to protected game of prey in Norway, this 
corresponds to a total sum of NOK 43,921,831 (Environmental Directorate, 2021b). These figures have been 
relatively stable over the past five years, although a slight increase in cases has been seen from 2020, 
which was a record low year for losses to wild game (Environment Directorate, 2021a). The loss rate 

today is approximately half of what it was 10 years ago, which is believed to be justified by shifting the 
grazing season to avoid the worst game season, plus other preventive measures from farmers and 
authorities (Environment Directorate, 2021a). The figure below shows that wolverine and lynx are the biggest 
threats to sheep on open pastures as of today. 


Sheep replaced per predator type 


Golden eagle 
10% 


Wolverine 


42% 


Figure 3.1: Percentage distribution of replaced sheep killed by wild game (Miljødirektoratet, 2021b) 


3.1.3 Marking of sheep 

The Norwegian Food Safety Authority requires that all sheep on pasture must be marked with a visual and 
electronic tag in both ears to indicate origin (Food Safety Authority). The color of the ear tag is often distinct 
for each farm in å grazing layer and can be used as an identifier at short distances to identify which farm 

a sheep belongs to (Hvasshovd, 2021). It is optional which color farmers use on their labels as long as they 
are not salmon pink or white (Food Safety Authority). 

The ear tag contains information such as the animal holding's ID number and individual number on the 
animal for further identification (Food Safety Authority). 
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Figure 3.2: Lambs with ear tags (OsID) 


Ties are used to mark how many lambs a ewe was released to pasture with at the start of the grazing 
season (Hvasshovd, 2021). With the help of ties, supervisors can easily identify how many lambs should 
accompany the observed ewe. There are established recommendations for which colors should be 

used for different numbers of lambs 

(NSG). NSG's recommendations for color coding on neckties in ewes are: 


- 0 Lamb: Red 

” 4 Lamb: Blue 
- 2 Lamb: Yellow 
- 3 Lamb: Green 


Figure 3.3: Ewe with tie and ear tag (OslID) 


3.1.4 Today's supervision routines 

According to the law, supervision of the sheep is carried out as of today at least once a week and the 
responsibility is distributed between the farms participating in the grazing team. But even if the responsibility 
falls on a specific farm, it is not necessarily the case that it is the farmer himself who goes on 

the inspection tour with the animals. Many farms have employees or outside helpers who contribute 
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by going on inspection trips to the pasture to lighten the farmer's workload (Hvasshovd, 2021). Because 
of this arrangement, there is not always a fixed number of people who contribute with supervision 
per season, which can create challenges if the notes from the trip are not well written. 


When a trip is carried out, it is important to note down observations along the way so that you can 
document them afterwards. This is important both in compensation cases, supervisory cases and for 
the farmers' own overview throughout the season. The traditional way of noting such observations 

is with pen and paper (Hvasshovd, 2021). Most people choose to use notebooks, and NSG has 
prepared both specified notebooks and 

standard forms in an attempt to make the notes more structured (NSG). 

The main problem with such note-taking becomes clear as soon as the sky fills with rain clouds. Taking 
notes on paper in rainy weather is a challenge that is not easily solved in any other way than changing 
the recording medium. 


Another relevant problem is the organization of the notes after a completed trip. 

If the notes are written down in å notebook, they must be transferred to another medium for 

storage in a common place. NSG's standard forms can be collected in a joint folder, scanned into 

a PC or the data can be transferred to NSG's Excel template (NSG). After the Norwegian 

Environment Agency created an electronic application for the replacement of grazing animals, the need for 
note-taking on å computer has increased significantly and it therefore requires more time from the farmer 
who will have to transfer the information from sheets or notes (Hvasshovd, 2021). Generating reports 

for such applications is also a time-consuming process if you have not structured the supervision data 
regularly throughout the season. 


As of today, the communication around the supervision visits takes place largely orally, both in terms 

of planning, implementation and observations. When a supervisor observes something out of 

the ordinary, the others in the grazing team will not know about this until they are notified verbally by the 
farmer who was responsible for the supervision round. It is also a challenge for each individual 

farmer to keep track of the observations carried out throughout the season and where the sheep were 
last seen, which can be very relevant when planning the route to follow (Hvasshovd, 2021). 


3.2 Existing solutions 


In this section, some existing solutions are described for streamlining the supervision of sheep on 
pasture, in addition to the collection of sheep at the end of the season. 


3.2.1 Findmy 

Findmy is a service that delivers an electronic collar they call E-bell. The sows wear the E-bell around 
their necks and are thus equipped with GPS tracking as well 

warning systems and a mobile application with maps and monitoring tools give the farmer a better 
overview of the animals (Findmy). The e-bell is a battery-powered device that sends signals at 

timed intervals with the position and status of the animal and is equipped with Bluetooth that makes it 
possible to connect and find the animal during inspection and collection using the mobile phone (Findmy). 
The service also provides å solution for Geofence (A geographically defined area that is defined digitally, 
not å physically defined area) so that the user is notified as soon as an animal is on its way out of 

the registered area (Findmy). 
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Findmy uses satellites to achieve the best possible coverage and today has coverage throughout Norway as 
long as the sheep is under the sky and not under rock shelves or similar that block the signal (Findmy). It is 
nevertheless stated that different topologies can affect the transmission conditions of the bells in various 
areas. Findmy recommends that you track the least 

25% of the sheep flock and up to 100% to achieve the best result. Each bell costs NOK 1,980 without 

VAT (Findmy). 


3.2.2 Teletrack 


Telespor is a service for electronic monitoring of livestock on pasture that uses a radio bell that is attached to 
the animal. The unit is equipped with GPS and a motion sensor that sends updated data to teletrack at 
predefined time intervals. The aim of the solution is to let the farmer see where the animals are on the 

map and send him/her SMS notifications when various alarms are triggered (Telespor). Such alarms can 
include that the animal has not moved for several hours, has stayed in the same place for a long time or 

the bell has not been able to report within a given time (Telespor). 


Telespor is å subscription-based service where you buy the bell for NOK 989 and then subscribe to the 
service for between NOK 99 and NOK 119 for 5 months of use a year. In addition, you have to change the 
battery in the bells after each season. Å battery costs between NOK 65 and NOK 75 and a bell has an 
expected lifespan of 5 years (Telespor). Telespor's solution uses Norgeskart's application to visualize 
individuals on å map, a service that costs NOK 50 per year (Telespor, 2022). As Telespor's solution is based 
on mobile services for reporting, there is a risk that sheep move outside the coverage area and that the farmer 
will not receive reports on the animal's status until it moves into the coverage area again. There can also 

be challenges with reporting if the animal is near a rock wall or similar (Telespor, 2022). 


3.2.3 Nofence 

Nofence's product is based on virtual enclosures defined by the user that define the areas in which the 
animals can move. In order to make the animals stay within the areas marked on the map, the 

animals are equipped with a collar that makes åa sound when the animal is on its way out of the area. The 
solution therefore requires that the animals be taught to understand how to handle the sound so that 

the animals move into the correct area again 

if they were to hear the sound (Nofence). Nofence supplies mobile applications for both Android and Apple 
where the system can be managed and the animals can be monitored (Nofence). 


Nofence says that on the basis of animal welfare, all adult animals in the herd must be equipped with 

collars (Nofence). The solution is subscription-based and has a price of NOK 799 per year if you use between 
1 and 9 pianos. Above this, you can use a fixed price of NOK 640. 

plus VAT per year or variable price of NOK 149 plus NOK 3 per grazing day. All prices are without VAT 
(Nofence). Communication with the herd takes place via the mobile network and it is recommended to 

have mobile coverage throughout the grazing area (Nofence). 


3.2.4 Smart bell 


Smartbjella offers a smart bell that is hung on the animal, records the animal's position via GPS and 

sends updated information to Smartbjella. The information that is generated can be observed by the user via 
a web application that shows where the animals are on the map and historical movement of the herds. 
Smartbjella also offers death notification, Geofence 

and time alarms that give the user notifications when animals have been stationary for a longer period of time 
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period, moves outside a certain area or an animal must have special follow-up such as 
vaccination (Smartbjella; Smartbjella). 


Smartbjella uses the mobile network to send signals, which means that signals will not be sent 
from the animal as long as it is outside the coverage of the mobile network. It can also cause 
problems for sending data if the sheep does not stay under the open sky (Smartbjella, 2022). 
Smartbjella costs NOK 999 per unit and is å subscription-based service with 

several plans that provide more or less data about the animals. 

The cheapest plan costs NOK 109 per year per bell, while the most expensive costs NOK 149 
with a minimum quantity of 10 units (Smartbell). 


3.2.5 Grazing snap 


Beitesnap is a registration and supervision tool for documenting animals on pasture and acts as 

a notification system between walkers and animal owners. The tool consists of a mobile application 
that is available in both the Apple app store and Google play. For walkers, the purpose is for them 
to be able to record observations of animals grazing while they are out walking. A registration 
provides information about the position and condition of an animal. This information will be 

directly available to the animal owner and added to the history of the grazing season. The 

mobile application also functions as a registration system for animal owners who can 

define grazing areas on å map and register events on grazing and supervision of the animals. 

The solution also delivers functionality for generating ready-made reports 

as documentation of supervision throughout a grazing season (Beitesnap). 


Beitesnap's solution costs NOK 1,200 excluding VAT per producer per year. This allows the 
producer to have 7 subusers. Use for walkers is free (Beitesnap). For grazing teams that shop 
together, users can get up to a 50% discount. The application works offline for areas that 

do not have mobile coverage (Beitesnap). Beitesnap no longer appears to be in operation as their 
website has not been updated since 2019, the application is not found in the Google play store 
and the application in the Apple App store no longer allows you to log in. 


3.2.6 Summary 


Several of the services provided today simplify and streamline the follow-up of animals on 
pasture through tracking, notification and registration of deviations by giving farmers direct 
updates and an overview of the animals available on the internet. All the tracking solutions 
mentioned in this section use mobile networks to report data from the animals. 

This means that the grazing areas have to have good GPS and tele-coverage for the solutions to 
work well. The exception to this is Beitesnap, which is more aimed at physical supervision and 
manual registration, but the system does not seem to be operational. 


In addition to the requirement for telephone coverage in the entire grazing area, several of 

the solutions are expensive and require investment from the farmer to put them into use. The 
table below shows an overview of estimated costs per system for investment in one unit. Several 
of the systems provide opportunities for several users to use the system at the same price, 

this is not taken into account in the table as it only presents the entry price for each solution. Prices 
are calculated by using the price of the unit plus any necessary additional equipment in addition 

to an average price of available subscriptions if the solution offers several 

subscription levels. The reservation is made that prices shown here are estimated and calculated 
based on information found on the suppliers' websites. Nor has an attempt been made to compare 
the functionality provided by each supplier with each other beyond the price of the solutions 

and which coverage areas they have. All prices are shown excluding VAT. 
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Solution Communication method Zones without coverage Price per year 


Findmy Satellite Under rock shelves or 1980 NOK 
next to the wall 


Fa 


Table 3.1: Overview of existing solutions 


Based on the data presented above, it appears that, as of today, there is a lack of solutions on the market 
that are aimed directly at manual monitoring of sheep on pasture. Although several of the solutions simplify 
the work of looking after the animals, it is still required by law that the animals must be looked after 

every week and this should be documented if the farmer wants reimbursement for lost animals during the 
season (Forskrift om velferd for småfe, 2005). There may therefore be room and a need for solutions that 
simplify this supervision. 


Most of the solutions presented in the table above are based on teledata for recording and disseminating data 
about the animals on pasture. lf you have grazing areas that are not covered by the telecommunications 
network, the data you receive from these solutions can be reduced and in some cases insufficient. 

Finally, many of the solutions presented above are expensive as they include physical loT (Internet of 

Things) products in addition to subscription solutions. 


To put the prices of the solutions in perspective, you can do å general calculation on an average lamb 
delivered for slaughter. According to Animalia, the average slaughter weight of a lamb in 2021 was 18.8 kg 
(Røe, 2021). According to the table for settlement prices for small cattle, a farmer will receive between 
NOK 592.95 and NOK 1062.95 for a lamb with this slaughter weight, the prices are exclusive of VAT and 
basic subsidy (Nortura, 2022). 


The team has, through its work with a review of existing solutions, identified that there may be a potential 
market for a solution that simplifies the manual supervision of sheep on pasture. Such a solution should be 
available in areas where there is no telephone coverage and allow the user to record data in offline 

mode. Ås such a system will be aimed at making the farmer's manual follow-up of sheep more efficient, 

the solution will cover a market which, as of today, is not directly covered by any of the other suppliers. The 
product has the potential to be å low-cost solution for looking after sheep compared to other solutions that use 
loT technology with devices per animal on pasture. 


3.3 Previous work 


Svein-Olaf Hvasshovd, who is the supervisor for this project, has been a supervisor for farmers with sheep 

on open field grazing for many years and has in-depth knowledge of the processes and systems that comprise 
this practice. The basis for this thesis and the issues raised are based on his experiences and 

previous projects that have been carried out in the area. 


3.3.1 Binocular mode 


After a long period of time overseeing field pastures, Professor Hvasshovd has experienced the need to 
be able to register sheep at the same time as using binoculars for 
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observation. As this was a challenging task with pen and paper, it was investigated 

more efficient and responsive ways of carrying out such registration of sheep (Hvasshovd, 2021). The 
results of the surveys concluded that one of the most relevant 

the way to solve this is that the user can use the screen of the mobile phone to swipe to the right or left to 
register sheep and that the phone gives feedback to the user using sound, so that the user does not 
have to look at the phone during 

registration. (Hvasshovd, 2021) These results were used as a basis when the development of the app 
started and no further research was carried out regarding whether there were more efficient ways to 
carry out such registration, beyond user tests of the implemented solution. 


3.3.2 Important data 

Through his experience of monitoring sheep on pasture, Professor Hvasshovd has identified 

a number of data that would be critical for farmers on inspection trips to record. 

This data is compiled in the original requirements specification which can be found in Appendix Å and 
includes: 


- Observed predators 

- Dead animals 

- Injured animals 

- Flocks of sheep and number of sheep 

- Details about each sheep such as color, earlobe and tie 
- Who made the trip 

- Inspection tour in map 


- Positions for registrations 
- Other events 


3.3.3 Map 

Professor Hvasshovd has also identified a number of needs that specifically relate to the use of maps and 
the recording of data in maps during the inspection round. The most important thing the app must be able 
to handle when it comes to map use is that the user must be able to select a section of the area that the 
user wants to walk in. This section must be able to be cached in the phone's memory so that it is 
available if there is no mobile coverage in the areas the inspection tour is carried out. 


The registration of flocks during the inspection tour must also contain information about where the 

user was when the flock was seen. Å line must also be drawn on the map between the 

registration position and the herd. The reason for this requirement is that, at a later stage, it is interesting 
to know where you were when you saw the herd and in which direction you saw it when you review the 
trip afterwards. 


When you are out on a trip, it can be very relevant for the user to be able to see previous trips and 
have information about where sheep have been observed in the past. This is so that inspection 
trips can be varied, but also so that it can be recreated 

past routes and identify areas where sheep often move. 


In the web application, it is also an advantage if, when you go through trips completed in the 
map, you can see grazing quality in the map. It may be relevant to be able to identify how the 
sheep moves in relation to the quality of the pasture as it can 

make visible which areas it is advisable to visit when collecting the sheep. 
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4 Own contribution 
4.1 Method and process tools 


4.1.1 Development methodology 

Before the development period began, the team identified tasks to be carried out and listed 
work tasks in broad terms. Based on this, a burndown chart was prepared to keep control of 
the development process in order to better estimate the time spent in the project. The full Gantt 
chart can be found in Appendix A. 


Progression plan 
Prog: 


ression plan masters project 2021/2022 


Mobile App main functionality 
Web App main functional lity 
Stretch goals 

Report and Documentation 
Project diary 

Report 


Figure 4.1: Section of the Gantt chart for planning the project 


Throughout the project period, the team has used a loose Kanban methodology as åa 

development framework. Kanban is a flexible development methodology where the focus is on 

not having too many tasks in progress at a time and tasks are included in the 

workflow as the team has the capacity to carry them out. The reason why the team has defined 

its development method as loose Kanban is that Kanban basically has å product owner responsible 
for defining tasks and prioritizing the backlog, 

which means not yet completed tasks (Atlassian). As the team only consisted of two people, 

the members alternated in this role. 


When using Kanban, you use å Kanban board where tasks are placed as cards on the board 
and moved to the right column based on the status of the task. During the project period, 

the team used GitHub as a versioning tool for the coding tasks and thus also Github's 

Kanban board. Most tasks were defined at the beginning of the project period and grouped into 
larger milestones. 
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Filter cards 


3 Todo H+ oe 2 In progress + oe 20 Done + ++ 
Q Tidligere turer 429 O) Feed es ++ WIP: Store trip upgraded eve 
by Certinax 29 opened by Certinax : ThoMot [5] 
Uke? 2 via? PI 
Oc 
O Ferdigstille app ves O Oppsett av API == 
Rt Q) Implementer fullført tur 
å by Certinax OD 2 of 3 tasks : 
å Certinax 
Uk >) +28 opened by Certinax AE 
å GP Uk 
P 2> 
O Rendeflex overflow i Logg liste v 
[bug ] Q Profilside - advanced 
O 3 of 4 tasks 
? F Certinax 
de 3) 


Q Design fullført tur 
+21 opened by Certinax 
5 Uke 5 

ked pull reque v 


$- Completed trip overview 


Certinax 
KOG 


To do Manage tomate In progress Manage Automated as Done Manage 


Figure 4.2: Kanban board for the mobile application project during the development phase 


Why Kanban: 


- Flexible workflow where the tasks are prioritized continuously suits well for smaller 
team 

- Provides å good overview of the tasks to be carried out 

- Limitation of active tasks imposes a greater requirement to complete one task before starting the next one, 
which ensures progress in the project 

- Gives a good overview of what has been done and when it was carried out 


As mentioned in the sections above, Github was used as a versioning tool together with Git, which is the cornerstone 
of code versioning. Github greatly contributed to seamless development between the two team members, where 
each member can continuously develop a part of the system and then ask the other for code evaluation before 

the changes are integrated into the project. The team therefore made diligent use of Pull requests, Code reviews 
and merge commits into the main project which lived in the Github cloud as a "single source of truth". 


4.2 Requirements specifications 


The requirement specifications in this section provide an overview of the functionality requirements for 

the mobile application and the web application. The functionality has been thoroughly worked out and 

defined based on the requirements specification that was originally drawn up together with Professor Hvasshovd at 
the start of the project phase. lt is based on his experiences and past 

research in the area. More about investigations and work carried out before the project phase can 

be found under the section "Previous work". The original requirements specification 

prepared in collaboration with Professor Hvasshovd can be found in Appendix B. 

The requirements specifications for the mobile application and the web application are further presented in the 
sections below. 


Based on the requirements specification, the requirements for the system have been divided into functional and non- 
functional requirements, shown together in the table below. 
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Functional requirements Not functional requirements 
Create profile and save/change/delete user Faster to generate reports than manual 
data creation 
Create/Edit/View grazing groups Easier to find grazing data/animal data about your 
farm than without the system 


detail 
Follows current laws and regulations regarding 
privacy and GDPR 


Generate standardized reports for a grazing Data is stored securely and efficiently 
season 


See grazing quality in grazing areas in the map 


Table 4.1: Functional and non-functional requirements for the system 


4.2.1 Mobile Application 

The mobile application's main purpose is to offer an overview of the user's profile, the grazing groups 
and activity in the groups the user is a member of, and the possibility of registering supervision 

visits. The requirements below are structured according to the app's main functionalities. 


- See recently completed trips in the 
grazing groups you are a member of 

- See details of completed trips by accessing 
a trip 

- Start a new inspection tour 


- See which beta soups you are a member of 
of 

- See recently completed trips in the 
grazing groups 

- See which farms are included in the 
grazing groups 

- See which members are involved 
the grazing groups 

- Manage the grazing group if one 
is an administrator 

- Add members 

- Add farms 


- Download map of area 


- Start an inspection trip 

- Register an observed flock of sheep in 
manual mode or in binoculars mode 
depending on the distance 

- Record lost animals or predator 
sightings 

- Register other information about the trip 

- Complete and see an overview of the trip 


- Upload your trips to the cloud 
- Change profile 


- Manage invitations to grazing 
groups 

- Delete profile 

- Log out 


Table 4.2: Overview of requirements for the mobile application's functionality 
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Based on the requirements presented above, a "Use case" was prepared to better illustrate the functions and 
activities a user should be able to carry out in the mobile application. The user is defined here as å person within 
the target group of the system which is specified in the section "Target groups". 


Opprett profil 


endre profil 


<<include>> 


Registrere 
detaljer 


<<include>> 


Se detaljer om 
tur 


mit «28: 
re 
Gå til Feed 
ko 
Brukeren må å” 
være 
innlogget NN 


Velg en 
beitegruppe 


Administrer 
beitegruppe 


Gå til 
Beitegrupper 


Se detaljer om 
gruppe 


Opprett 
beitegruppe 


Figure 4.3: Use case for the mobile application showing potential usage patterns 


Through the design of the requirements, some technical requirements for the mobile 

application were also reduced. The technical requirements that were drawn up are shown in the table below. The 
original prepared list can be found in appendix B. These technical requirements are used as åa basis for choosing which 
technologies the project is made with. 


Technical requirements for the mobile application 


The app must be available on iOS and Android to reach the vast majority of users 

Must support Android version 10 "Queen Cake" or higher as it is the latest version with security support 
(endoflife) 

Must support latest version of iOS version 12.4.x or higher, this includes iPhone 6s and later (Apple) 


Must have support for GPS 


Must be able to process and display map data offline (Desired map data from the mapping authority) 


Must be able to upload log data to the cloud via wifi 


Table 4.3: Technical requirements for the mobile application 
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4.2.2 Web Application 

The main purpose of the web application is to give the user an overview of data collected throughout 
the season, an overview of the user's profile and groups, in addition to generating reports based on 
the season's data for submission to the Norwegian Environment Agency. 


Dashboard 


- See which groups you are a member of 

- See recently completed trips in the grazing groups 

- See which farms are included in the grazing groups 

- See which members are in the grazing groups 

- See recently completed trips in the grazing groups you are a member of 


- See details of completed trips by accessing a trip 
- See the grazing quality in the grazing areas on the map 


- Choose a grazing season to generate for 
- Select pasture group to generate for 

- Generate report based on selection 

- Printing / saving the report 


Profile 
- Change profile 


- Delete profile 
- Log out 


Table 4.4: Overview of requirements for the web application's main functionality 


The web application's use case presented below presents activities and functions åa user should be able 
to carry out in the web application. The functionality is based on the requirements presented 
in the table above. 


non endre profil 
PE 
Txte) 


Brukeren må f.-- 


være 
innlogget kal sa nnG <sinclude>> / Se detaljer om 
= (dom i - 
Se detaljer om 
gruppe 


Figure 4.4: Use case for the web application showing potential usage patterns 
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4.3 Concept design 


On the basis of the designed requirements specification and the use case diagrams discussed in 
the section above, a first draft of what functionality the system should contain was prepared. The 
way the team worked was by going step by step through the system and 

charting a flow that felt natural. Each Post it represents a step where the user can perform an action 
or observe data, different action areas in the flow were given the same color. The entire flow 

for both the web application and the mobile application can be observed in appendices C 

and D. Figure 4.5 shows a section of the application flow for registering a herd. 


Figure 4.5: First draft application flow for registering a herd during an inspection trip. 


After the functional flow in the application had been mapped, a conceptual model for the 

system was developed. The conceptual model was prepared with a background in theory 

that by preparing such models before designing the user interface, one can help make the concepts 
presented by the application clearer and more logical for the user 

(Johnson, 2008). The relational model that shows the relationships between the different concepts 
in the application is shown in figure 4.6. Each concept has its own attributes and is linked to 

other concepts in the model through relationships. Each line is numbered to illustrate the number 

of other concepts that can be related to a single instance of each concept. More details on the 
conceptual model can be found in Appendix E. 
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User 
Email 
First name 
Last name 
Picture 
Admin status 


Group affiliations 


Performed trips 


(0,n) 


(0,n) (0,n) 


Name 
Members 


Trips 


Farms 


Belongs to 


Grazing Group 


lember o' 


(1) (1,n) 


0,n 


Belongs to 


(1) 


reates 
Perform: 


(1) 


Flocks 


Distance 
Positions 


Events 


(0. 


> 


,n) 
(1) 


Title 


Description 


Category 


Position 


Sheep 


0,n Belongs to, (1 Lambs 
Note 


Positions 


(0,n) (0, n) 


Color 


Tie color 


Condition 


Tag color 


Note Condition 


Note 


Figure 4.6: Relational model for the system 


In order to gain better insight into the target group and illustrate the problems users face today, 
the team developed two "personas". Personas are used to represent typical users of the 
solution in order to better understand the users' wishes, needs and expectations (Rikke Friis 
Dam, 2022). The background for the personas developed in the project is interviews conducted 
with Professor Hvasshovd and based on his experiences in the field. The personas that were 
designed have different characteristics and represent two different users with different needs 
and wishes for the system. Through these personas, it became easier to visualize an end user 
and make the process more user-centred. Figure 4.7 shows one of the personas that was 
prepared. Both personas can be found in appendices F and G. 
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DT4180 HC! — 2021 


Bonde 50-60 


Odd Larsen 


Hardt arbeid er realt arbeid 


Hd" 


Bio 

« Odd er en hardtarbeidende og 
selvstendig bonde som er opptatt av å 
gjennomføre oppgavene sine på en 
ordentlig måte i henhold til loven men er 
også opptatt av at ting skal være 
praktisk. 

Mål 

Følge lover og regler om dyrehold på 

utmarksbeite 

« Gjennomføre jobben sin på en effektiv 
måte 

« —Drifte på en skikkelig, men også 
profitabel måte 


Frustrasjoner 

« Må forholde seg til andre som ikke 
gjennomfører oppsyn skikkelig 

« For mye arbeid å produsere rapporter for 
dokumentasjon til myndighetene 

« Vanskelig å finne igjen sau om høsten 


ØNTNI 

Personlighet 
Ekstrovert [] Introvert 
Sansing I] Intuisjon 
Tenking Å Føling 
Dømming [] Oppfattelse 
Passiv O Aktiv 
Lojal DO Flytende 
Oppførsel 
* Gjør gjerne jobben selv for at den skal 

gjøres skikkelig 


* Arbeider effektivt 

« Behandler sauene sine godt og blir 
frustrert av tap ettersom det koster ham 
mye penger 


Oppgavespesifikk seksjon 

« Vil ha et felles system for strukturering 
av informasjon 

«Vil ha tilgang til informasjon om sine 
sauer så raskt som mulig 

«Vil ha en mer effektiv måte å generere 
rapporter til myndighetene på 


Bonde Motivasjoner «Vil ha et system som er enkelt å bruke 
sans] | —— 

METER Oppdal —— —— 

POETER Innadvendt ————— 


Hardtarbeidende Selvstendig 


Figure 4.7: Odd Larsen is one of the two personas in the project 


4.4 Design and layout 


There were no guidelines for what the new system should look like, giving the team free rein 

to work out the design. The choices are nevertheless based on literature and known 
conventions, to ensure as good a user experience as possible and compliance with requirements 
and guidelines on universal design have been followed. The design and layout of the application 
has been prepared iteratively through the use of user tests and continuous evaluation of the user 
experience at different stages of the development process. 


4.4.1 User experience 


User experience is about how users experience an application, how easy it is to use and how easy 
it is to understand existing functionality. 


When preparing the app's design and structure, the team has focused heavily on 

information architecture to create a logical structure that is intuitive for the user. 

The team has arrived at which information has been assessed as most important for the user 
by basing itself on Professor Hvasshovd's experience in the area. The mapping consisted of 
first reviewing the prepared requirements specification and then grouping the most important 
functions and information, so that a clearer hierarchy of needs emerged. 

It has been an important element that users do not feel overwhelmed by too many choices, 
which has also influenced the app's basic design. 


On the navigation bar in the mobile application, three of the four main areas in the 

app can be identified, all of which allow the user to navigate deeper in the hierarchy. Since the 
user is on, will be highlighted in the navigation bar at all times. This marking in addition to the 
back arrows that appear on the top line when you have navigated 
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down the app hierarchy to reach å specific function helps to keep the user from getting 
confused about their location. 


nt 


Hjem 


Figure 4.8: The navigation menu in the mobile application and arrow for back navigation in 
the top menu in the mobile application 


Throughout the preparation of the design, there has been a focus on complying with Don 
Norman's design principles which aim to improve user experiences and make the use of å 
product more intuitive (Batterbee, 2020). In addition, both Jacob Nielsen's principles for 
interaction design and the Gestalt principles have been used as a basis for the application's 
layout and design (Nielsen, 2020) (Sandnes, 2018). 


An example of such elaboration is that there has been a consistent focus on text on buttons and 
other elements being comprehensible and giving the user a clear indication of the 

functionality behind it. This is important to prevent the user from becoming confused as to 

what functionality is available or from the user performing actions they did not want to perform. 
and are important elements in Don Norman's seven fundamental design principles 

(Batterbee, 2020). Figure 4.9 below shows an example of this where both text and icons are 
used to indicate to the user which function lies behind the buttons. 


ss  Oppdalsgruppa 
ho Innstillinger > HJT 28.5.2022 19:01 
3 & Hans Karlsen 
seg Hedmarksgjengen 
%  Lastopp nytur på JPL 23.5.202219:04 
H42 Mons Arnesen 
sr9eg Oppdalsgruppa 
Mine invitasjoner > VEE 21.5.2022 17:50 
HE Anna Fredriksen 
Figure 4.9: Buttons for selection on the profile Figure 4.10: Buttons for selecting a trip on 
page in the mobile application the Home screen 


Through the mobile app and the web application, there has been a focus 

on letting interaction elements look the same so that it is intuitive for a user that the element 
can be interacted with. Figure 4.10 shows the interaction elements for opening a tour 

on the home screen. One can observe that the elements look similar to the buttons 

on the profile page, where each element has a leading element plus descriptive text for the trip 
or the page you are navigated to. This follows Jacob Nielse's principles of "Consistency" 

to meet users' expectations (Nielsen, 2020) 


Another design pattern in the mobile application, which falls under the "Consistency" 
principle, is the use of the round action button on several pages. This button is always found 
on the same styed and indicates that something new can be registered or added to 
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this page. Through the app, this button works to create a new trip, start a new trip, to add å new 
pasture and to register a new flock of sheep. 


Figure 4.11: Overview of the different action buttons in the mobile 
application 


In order to offer the user a consistent experience in both the mobile application and 

the web application, emphasis was placed on reusing the same color expression and 

element design in both solutions. In both applications, theme components were set up 

for color selection and design, so that if something had to be changed at a later stage, it would 
be easy to make adjustments in both applications. 


4.4.2 Images and icons 


On å general basis, icons and images are only used as additional information, in addition to text 
in both applications to meet accessibility requirements. The focus on accessibility is further 
discussed in the section "Availability". Nevertheless, icons are åa widely used and recognized 
convention in mobile applications and they have also been used in some places in the 
application to illustrate functionality or as a type indicator. 


An example of this is the icons on the action buttons as illustrated in figure 4.11. Here, the 
icons indicate different functionality based on where in the app the user is. Another example is 
the gear or menu icon found in the top bar when completing a trip which opens different menus 
with choices for the user. 


Icons are also used in the map solutions in both mobile and the web application to illustrate 
registered events, flocks and where the user has moved. The icons for registered events and the 
user's location are taken from icon libraries that offer free icons for use in personal and commercial 
solutions. The icon for registering sheep flocks is designed independently in Figma. 


Figure 4.12: Icons used in the map solution 


4.5 User testing of layout and design 


As introduced in the "Method" section earlier in this report, several user tests have 
been carried out throughout the project to ensure that the final product 
meets the wishes and expectations of the users. 
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Before the development process began, a paper prototype was developed as a "proof of concept" 
which was tested on users to identify whether the structure and main functionality of the 

mobile application was intuitive. Based on the results of this test, a more detailed prototype was 
prepared in Figma. Figma allows developers and designers to implement application-like 
behavior and functionality in the prototype, so that users get a better experience of how the flow, 
feel, navigation and expression of an application will be in the final product (Figma). 


In this section, the tests of the paper prototype and the Figma prototype will be presented in 
addition to the results that formed the basis for the development of the final product. The figure 
below shows the sequence of tests throughout the project and which tests will be covered in this 
section. The last test shown in the model will be described in the section "Results" i 

this report. 


Proof of concept | Test | Figma prototype Test ) Applikasjon MC 


Figure 4.13: Test order in the project and relevant tests for the section 


4.5.1 Conducting user tests 

When all the user tests were carried out, a test plan was drawn up where the test was divided 

into three parts. The first test section consisted of information to the tester regarding the 

conduct of the test and the purpose of the application. Å detailed description of the 

information provided can be found in Appendix H. In the second test section, the user 

was asked to perform several tasks given by the test administrator, without guidance and 

to the best of their ability. The user was asked to describe their thought processes along 

the way and what problems or other thoughts arose during the execution of each task. One person 
in the team was responsible for following up the user and carrying out the test, while the other team 
member was responsible for noting events and relevant thoughts the users had. A list of all the tasks 
given during the various tests can be found in Appendices I, J and K. The last part of the test 
consisted of a freer section where the user was asked planned questions about specific parts 

of the system and the user could give other feedback. These questions can also be seen in Annexes 
I, JandK. 


4.5.2 Paper prototype, Mobile application 

The test was carried out by one of the team members acting as a "Wizard of Oz", who was 
responsible for keeping track of the application's status as the user wanted to navigate through 
the prototype. This meant changing pages, presenting modals and showing feedback on 

what the user wanted to do. The main purpose of carrying out this type of early test of the solution 
was to get feedback from users on the structure and flow of the application without the focus 
being shifted to the visuals such as colours, icons and the like (Babich, 2017). The figures 

below show an extract of the paper prototype that was developed, more images of the prototype 
can be found in Appendix L. 
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Figure 4.14: Home screen Figure 4.15: Overview of Figure 4.16: Start new trip 
paper prototype grazing groups screen 


The paper prototype of the system was tested on three users, one user with domain-specific 
knowledge and two general testers. A summary of the findings from the test of the 

paper prototype is presented in the table below. PP in the table refers to "Paper prototype problem" 
and PL refers to "Paper prototype solution" 
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Summary of the paper prototype test results, Mobile application 


Suggested Salon 


Domain expert PP1: Farms don't make sense PL1: Remove farms as the 
as a separate choice as there is information about them already 


no unique info about them exists in the grazing group entity. 
there. 


Domain expert PP2: Binoculars mode is too much PL2: Shorten the binocular flow and 
detailed. You will never have allow the user to exit the registration 
the opportunity to "go back" and when they have finished 
record more details about yourself | registering the number of sheep if 
sheep they cannot see color 


General user 1 PP3: Didn't understand what Farms PL3: See proposed solution PL1 
in the navbar had as purpose 


General user 2 PP4: It might be relevant to be able PL4: Add which farm each supervisor 
to see which farm each belongs to when showing tours 
supervisor belongs to within 
a grazing group 


General user 2 PP5: A bit messy under binoculars PL5: See proposed solution PL2 
the registration 


General User 2 PP6:|Some general confusion PL6: After a short interview with 
regarding what are buttons and the test subject, it is revealed that 
what are not this is more due to the flat paper 

prototype than design choice 

General User 2 PP7: A bif confusing that PL7: The naming on the front page 
events on the front page are not is changed to "Feed" as this fits better 
the same as events with the data actually displayed 
you register on tour. there 

Table 4.5: Summary of the paper prototype's results (Thora Mothes, 2021) 


Based on what was found in the test of the paper prototype, it was decided to remove "Farms" from 
the navigation menu, as several of the test subjects did not see the usefulness of the entity. 

Farms instead only became part of åa grazing group. One user mentioned that it could be useful to 
see which supervisor belonged to which farm, but after discussion with the domain expert it was 
determined that this was not a priority area. In addition, it was revealed that the design and layout of 
the binocular registration was far too detailed. Based on this feedback, the flow in binocular mode 
was reworked to better meet the users' wishes and expectations of the functionality. 


4.5.3 Figma prototype, Mobile application 

Based on the feedback received when testing the paper prototype, the team developed å new 
prototype in Figma. Through the use of Figma, it was easier to show the users what the flow 

would look like in å real application, emphasis was also placed on some of the finer details in the 
application in addition to the overall user experience. The Figma prototype was designed according 
to WCAG standards (W3C Web Accessibility Initiative WAI, 2018) 

and it was emphasized to follow design principles such as Jacob Nielsen and Gestalt (Nielsen, 2020) 
(Sandnes, 2018). The images below show an excerpt of screenshots from the Figma prototype. For 
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for a full overview of the Figma prototype see appendix M and for a full overview of the 
navigation structure that was created for testing see appendix N. 


Antall dyr 


Ø palføret Beitegruppe Dalføret v 


12.09.21 0 Grå sau 0 Grå lam 
Rød Gård - Per Stålesen 


Aktivitetslogg 


Beiteområde Vestre område 
0 Brun sau 0 Brunt lam 


Tregrensa i 
09:08:21 Last ned kart over beiteområde ng ikke O Sort sau oser Um 


Gul Gård - Jan Johansen 


Dalføret 
05.08.21 
Blå Gård - Truls Nilsen 


Dalføret 


09.07.21 
Rød Gård - Svein Petter Olsen 


Tregrensa 
06.07.21 


Brun Gård - Rita Rønning + 


1 
Beitegrupper Profile 


Figure 4.17: Home screen Figure 4.18: Start trip screen Figure 4.19: Binoculars mode 
for registration of sheep 


The user testing of the Figma application was carried out in two rounds. In both rounds, 

the system tested on the domain expert, and three general users. Feedback from round 
number one was assessed and implemented in the solution before test round number two was 
carried out. The tables below present the problems and the potential solutions, 

identified through the two user tests of the Figma prototype. 
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Summary of Figma prototype 1's test results, Mobile application 
Suggested Solution 


Domain user F1P1: A bit confusing that man 


had to click the big button to 
get it to add or remove 
sheep in binoculars mode, 
expected to be able to swipe. 


Domain user F1P2: One should be able to leave 


General user 1 F1P 


General User 1 F1P4: 


General user 2 F1P 


General user 3 F1P6:: 


binocular mode for registration 


after only having registered 
the number of sheep. 


: Does not see the need for 


had to enter numbers to add 


mode looks like something you 


can swipe and not something 
you can click. 


: Å bit difficult to understand 


that you can switch between 
binocular mode and manual 


mode, but understood after a 
while. 


Maybe not needed 
input fields to enter how 


many sheep are seen in manual 
mode. 


F1L1: This is due to limitations 
in Figma. It won't work like that in 
the final solution. 


F1L2: This is already an 

option through the button in the upper 
right corner. It is not considered that 
more ways to break the flow are 
needed. 

F1L3: Change input fields to buttons 
to add or remove numbers 


sheep. 


F1L4: See solution F1L1. 


F1L5: No solution required 


F1L6: See solution F1L3. 


Figure 4.20: Summary of Figma prototype 1's results (Thora Mothes, 2021) 


One of the main elements the users registered during the execution of the test was that the large 
button in binocular mode for registering sheep looked like åa button that could be swiped or dragged 
across the screen, whereas in the test you had to click on the pages. The reason for this was 

not in design, but in limitations in Figma, where it is not possible to make an element swipeable 
more than one way at a time. This was nevertheless evaluated and taken forward into production as 
an indication that the designed button was intuitive for swiping. 


Another element that was very relevant for further design was that several users gave feedback that 
the input fields in manual mode were not intuitive for registering sheep. One of the users noted that 
buttons would have been better than input fields. This was implemented in the Figma prototype 
before the next test was carried out. 
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Summary of Figma prototype 2's test results, Mobile application 


Suggested solution 


Domain user F2P1: The buttons to add sheep could F2L1: Increase the size of the plus 
be bigger. and minus buttons during manual 

registration. 

Domain user F2P2: It seems that it F2L2: Add functionality to cancel 
There is no mate to cancel registration of a herd by splitting the 
registration of a herd in the registration button 
map in half. 

General User 1 F2P3: Thb map could be F2L3: Taken forward as a design 
larger on the start trip screen choice for 

application development 


General user 1 F2P4: Could be nice to F2L4: Add comment field on each 
could enter a sheep in case there are 


comment on a single sheep specific things to note. 
General User 2 F2P5: There is no way to mark F2L5: Add button to indicate 
damaged sheep damaged sheep 
on. 
General user 2 F2P6: Not possible to see which grazing | F2L6: Add the grazing group name to 
group you are in when you go for | the menu while walking 
a walk 
General user 3 F2P7: Cannot cancel registration F2L7: See solution F2L2 
in map when clicking on the 
flock icon 


Table 4.6: Summary of Figma prototype 2's results (Thora Mothes, 2021) 


Through test number two of the Figma prototype, several new problems were uncovered. 

The team suspects that the reason more problems were uncovered in round two was that users 
became more and more familiar with the solution they were testing. The most significant of the 
shortcomings identified was that there was no way to cancel the registration of flocks in the 

map when entering marking mode. This was included as an important element in the development 
phase in addition to the other elements which mostly consisted of improvements in relation to 

the user experience and additional registration details. 


4.5.4 Figma prototype, Web application Å Figma 

prototype was also developed for the Web application. In the design, emphasis was placed on 
highlighting the most important and most relevant information and that the user should have 
access to the desired information with the fewest possible clicks. Below are two images of 

the final Figma design. The entire Figma prototype can be seen in appendix O 

and the navigation structure can be found in appendix Q. 
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Dashbord 


sesong 202 EEE 


Ted Hansen 


Døde sauer Turer gått Rovdyr sett 
d 2 2 2 


Frøysa Gård 


Årets turer Rælingen Gård 


Dato Oppsynsperson 
Rygge Gård 
04.01.2022 Ted Hansen 


Med! mer 
20.01.2022 Kim Tronsen å 

Ted Hansen 
02.02.2022 Age Normann 


Kim Tronsen 
05.02.2022 Tore Fransen 


Åge Normann 
24.02.2022 Kim Tronsen 


17.03.2022 Ken Yee Tore Fransen 


01.04.2022 Åge Normann Kan You 


Figure 4.21: Dashboard in the web application. 


GrazingGroup 1 


Ted Hansen - 04.01.2022 


Flokker 
Flokk I 


Flokk2 
pre) 
Flakk 3 
TF sa * 4 harr - å 10:08 


Å ham «100 


FAK ar Må 10:09 


je Mar 
Hendelse tittet I 
Cweht dyr «be 1000 


Hendetse tittet 2 
Rod 1203 


Hendelse titel 3 
Motat - Må 1003 


Flokk 1 


Art ss 


Karmen 

låtar qunen soke et aeret onsenteene at pårdrg 
ØK. med do vanns here hndd dar: at brass et 
delene mye al ogå Lit nede at rrkver verken 
Gam mostud ste laber Ukarreo iborts pest ut 
pa pan ag LOM pen Fer se Et 


Figure 4.22: Overview of a completed trip. 
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The table shows the overview of problems and solutions that were identified through the user test. 
Which questions were asked and more detailed answers can be found in Appendix P. 


Summary of the Figma prototype's test results, 
Web application 


Suggested solution 


Domain user F3P1: Nb line found F3L1: Adding a line to the map inside 
between registration position and a trip. 
registered herd in the map 

Domain user F3P2: Wanted to see pasture F3L2: Implement possibility to see 
quality in the map. grazing quality in accordance with 


a trip. 


General user 1 F3P3:|A bit unclear with a button to see F3L3: Use the dropdown to select the 
more trips. relevant season. 


General user 1 F3P4:|No possibility to see what the F3L4: Add legend for map icons. 
different icons in the map mean. 


General user 2 F3P5: |Will be able to click on the map F3L5: Make icons in the map 

to see info about flocks and events. | clickable to provide more information 
about them. 

General User 2 F3P6:1 A bit hard to know F3L6: See F3L4. 
what all the icons in the map 
mean. 

General User 3 F3P71 Å bit hard to see F3L7: Make the design of non- 
difference between what are buttons flatter so they don't look 
buttons and what are not. clickable. 


Table 4.7: Overview of the results of the user test of the Figma prototype for the web 
application 


The domain user had some points (see F3P1 and F3P2), regarding data that was not available in the 
Figma prototype. This was noted down and taken on to the development stage. The 

other testers gave feedback about data in the map being unclear and that some of the elements in the 
design were unclear when it came to whether they were clickable or not. This design was revised during 
the development phase and additional information around the map was added. 


4.5.5 Conclusion 

After the completion of the user tests and evaluation of the feedback, the final flow of the applications 
and the system was determined. The figures below show simplified ones 

illustrations of the flow in the mobile application and the web application after revisions according to 

the feedback the team received through the tests held. Based on the completed iterative design process 
with the help of user tests, the development period was started. 
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Figure 4.23: Final application flow in the mobile application 


GrazingGroup 1 
Dashbord Ted Hansen - 04.01.2022 


Table 4.8: Final application flow in the web application 
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4.6 Product 


After several user tests of the solution had been carried out, where both the flow and the design of 
the system had been revised, the development phase began. The development phase was the 
longest phase of the project and lasted until a few weeks before project completion. 

The final product resulted in an almost launch-ready system. In this section, the final 

system is presented, consisting of a mobile application and å web application. 


4.6.1 Mobile Application 


The mobile application offers the user functionality to: 


- Create, manage and delete your user profile. 

- Create, manage and delete grazing groups. 

- Accept invitations to grazing groups. 

- Carry out inspection trips with registration of observations. 

- Upload to the cloud after completed trips. 

- Possibility to evaluate previously completed trips in the grazing groups in the section. 


In this section, these functionalities will be presented in greater detail. 
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4.6.1.1 Create user 


Logg inn via den magiske linken med mailen din 
under 
Email 


Email 


Passord Oo 


Opprett konto Glemt passord 


Figure 4.24: Login page for Figure 4.25: Profile creation in the 
the mobile application mobile application 


When a user accesses the app for the first time, they are greeted with a login screen. 

None of the pages in the application are accessible without logging in as all functionality in the 

app relates to data that is confidential to the user who has registered it and those the user wishes to 
share this data with in the grazing team. If the user does not have an account, he/she can create 
one by clicking on create account. 


To create an account, the user must register their email and receive å magic link. 
The link that is sent to the user's email serves as verification of the email, and the 
allows the user to log in for the first time. 
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Personvernerklæring 


Fullfør regreringsprosessen ved å fylle ut navn og 
passord Personopplysninger vi samler inn 


og behandler 


Grunnleggende informasjon 

Navn. 

Kontaktinformasjon 

E-postadresse. 

Brukeraktivitet 

Oppsynsturer, beitelag, gårder og 
posisjon. 

Brukerhistorikk 

Historikk av oppsynsturer, beitelag og 
posisjon. 

Cookies 

Informasjonskapsler blir brukt for å 
håndtere innlogging, kryptert passord og 
for brukerdefinerte innstillinger i 
applikasjonene. Informasjonskapslene 
har en standard levetid på 60 minutter, 
men utvides ved kontinuerlig bruk av 
tjenestene. 


Fornavn 


Etternavn 


Passord FO) 


Gå til logg inn Avbryt opprettelse 


Hvordan vi bruker 
personopplysningene 


Grunnlag for databehandling 

Data vil bli behandlet basert på samtykke 
fra bruker av applikasjonen. Din 
informasjon vil bli samlet inn, organisert, 
lagret og brukt i applikasjonen i 


Figure 4.26: Registration of details when Figure 4.27: User terms for approval of profile 
creating a profile creation 


Before the user can log in, he/she must approve the terms of use in line with the Norwegian Act 
on the processing of personal data (GDPR) (Government, 2019). If the user does not approve 
the terms, no email will be sent. If the user chooses to approve, he/she will shortly receive 

a login link to his/her email. 


After the login link is clicked, a validation token will be approved in the application and the user 
will be asked to update their information. Once this has been completed, the user will be able 
to log in with their login information. 
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4.6.1.2 Home screen/Feed 

When åa logged in user opens the app they will be greeted 
of the Home screen which contains a Feed of the latest 
activities in the grazing groups the user is a member 

of. Here you can see when the last trip was made 

and who walked it. For more information about each 

trip, the trip can be accessed by clicking on it, and the 


user will be sent to a separate page with an 
Hedmarksgjengen overview of the trip. 


23.5.2022 19:04 


Oppdalsgruppa 
| 28.5.2022 19:01 


Hans Karlsen 


Mons Arnesen 


At the bottom corner you will find åa button that allows 
Orpdalsounne the user to start a new inspection tour. It is placed on 
Aonebrednksen the front page so that it is as easily accessible as 
Oppdalsgruppa possible. 
13.4.2022 17:03 


Anna Fredriksen 


In the navigation menu at the bottom of the 
page, the user can navigate between the different 
main pages in the application. 


Oppdalsgruppa 


3 gårder, 5 oppsynspersoner 


Figure 4.28: Home screen in Hedmarksgjengen 
the mobile application 2 gårder, 3 oppsynspersoner 


4.6.1.3 Grazing groups 

On the main page Grazing groups , the user gets 

an overview of all grazing groups he/she is a part of. 
Each grazing group is shown with a name, how many 
supervisors and farms there are in each group. 

Each farm is also shown as an icon on each item 

in the color of the farm. This is the same color the farm 
has on the ear tags of its sheep and is chosen by the 
farmer himself when a farm is added to the group. 


At the bottom corner you see a button almost identical 
to the one you saw on the Home screen, but with a 
different icon. The icon here indicates that a new 


» 
aC 


grazing group can be added. The structure for Beitegrupper 
adding a grazing group is made the same as on the 
previous page to make the operation of adding å new 
element (here grazing group or trip) as 


intuitive and recognizable as possible. Fgue TG grOUP SEN 
the mobile application 
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er VJ 21.5.2022 17:50 
Statistikk SHE Anna Fredriksen 
Skadde dyr: 0 Turer gått: 3 R Oppdalsgruppa 
Døde dyr: 2 Registrerte dyr: 28 Jult Wu 13.4.2022 17:03 


Anna Fredriksen 


Siste aktivitet Medlemmer 


sg Oppdalsgruppa rå Anna Fredriksen 
Lø 28.5.2022 19:01 
Å FE AN 


Hans Karlsen 
Ra 
er G Mons Arnesen 


Oppdalsgruppa 


4 21.5.2022 17:50 N 
Anna Fredriksen Q Odd Larsen 
F Oppdalsgruppa E Hanne Hove 
1 13.4.2022 17:03 


- Anna Fredriksen løn 
Å > Hans Karlsen 


Medlemmer 
Gårder 


GS Røed 


Anna Fredriksen 


Odd Larsen 
: SS Havstein 
| Mons Arnesen 


SG Jahr 


Hans Karlsen 


Figure 4.30: Upper part of å Figure 4.31: Lower part of å grazing 
grazing group page in the mobile application group page in the mobile application 


When a user accesses a grazing group, he/she will be able to see all information about 
the group. This includes statistics on some of the most important figures, trips taken in the 
group, which members are in the group and which farms are in 

the group. 


If the user is an administrator in the group, å small gear appears in the top right corner of the 
application bar. If the user clicks on this gear, the user can manage the group, remove trips, 
remove or add members, and remove or add farms. 


At the bottom right corner you will again find the button to start a new inspection tour. This is to 
make the functionality as accessible as possible and that it may be natural for some users to 
want to start a trip from the grazing group in question. 
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8 Anna Fredriksen 


Statistikk 
Skadde dyr: 0 Turer gått: 3 
Døde dyr: 2 Registrerte dyr: 28 


Medlemmer 


å Anna Fredriksen 


EN 
GA) Mons Arnesen 


Siste aktivitet 
* Oppdalsgruppa 
Ji 28.5.2022 19:01 

Hans Karlsen 


Odd Larsen 


Hanne Hove 
Oppdalsgruppa 

4 21.5.2022 17:50 

* Anna Fredriksen 


«954  Oppdalsgruppa 
HL 13.4.2022 17:03 


Anna Fredriksen 


Hans Karlsen 


Legg til Medlem 


Gårder 
GS Røed 


Medlemmer 


å Anna Fredriksen 


ØG -Havstein 


ÆR) 
År 
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ae 


Q Odd Larsen 
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e Jahr 


+ Legg til Gård 


Figure 4.32: Administrator mode in a Figure 4.33: Administrator mode lower part 


grazing group 


When administrator mode is activated, icons appear next to all elements that can be managed. 
For members and farms there are three options, the option to add, change or delete. You can 
also delete existing trips in the group. When you have finished editing the group, you can click 
on the cross that has replaced the gear in the upper right corner, to return to normal mode. 
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Legg til medlem Fjern medlem Endre rolle 


Er du sikker på at du vil fjerne 


a dette medlemmet? Vil du endre rollen til denne 
post 


brukeren? 
Brukeren vil miste tilgang til alle 


beitegruppen 


Avbryt — Fern medlem Avbryt — Lagre 


Figure 4.34: Modal for Figure 4.35: Modal for to Figure 4.36: Modal to 
adding a member remove member modify a member 


As an administrator, you can manage the members of a grazing group. To add a user as åa 
member, you must know the user's email address. The system will then check whether 
the user exists and either send an invitation to the user associated with the email or 

notify the administrator that there are no users with this email. 


For existing members, the administrator has the option to change the role of other members. 
Here you can change the status of each member between member and 
administrator. To remove åa member, the administrator must confirm this. 
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Endre farge 


Legg til gård 


Fjern gård 


Gårdsnavn 


Avbryt Lagre 


Er du sikker på at du vil fjerne 
denne gården? 


Avbryt Fjern gård 


R G B A 


RGB "198 50 39 100% 


Figure 4.37: Modal for Figure 4.38: Modal for Figure 4.39: Modal to 
adding a farm removing a farm change the color of a farm 


If you want to add a farm, you enter the name of the farm and choose which color the farm 
should have. The idea behind the choice of color on a farm is that this color matches the 

color the farm uses on the ear tag on the sheep. When registering a flock of sheep, you will 

be given the opportunity to register the color of the ear tag based on which farms are included in 
the grazing team. 


If you want to remove a farm, you must first confirm that this is what you want to do, and you 
can change the color of the farm at any time should this be relevant. 
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4.6.1.4 Profile 


Hanne Hove 


å Hanne Hove 


Innstillinger Innstillinger 


Last opp ny tur 0) > 
Mine invitasjoner Øv > 


Last opp ny tur 


Mine invitasjoner 


Logg ut Logg ut 


e 
Profil 


Figure 4.40: Profile screen Figure 4.41: Notifications shown in the profile 
in the mobile application 


The profile screen shows the name and picture of the logged-in user as well as presenting him/her 
with several choices. Settings allow the user to control their user information and 
update it. Here the user can also delete their profile. 


Upload new trip allows the user to upload a recently completed trip to the database. As many 

of the grazing areas may be out of coverage, a trip will be registered offline and then the user will 
have to upload it to the database when they get internet access back. If a trip is waiting to be 
uploaded, a notification chip will appear here. 


My invitations shows invitations the user receives to new grazing groups. If there are pending 
invitations, a notification chip will appear here. The user also has the option to log out via this 
screen. 
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Hedmarksgjengen 


Avslå invitasjon 


Ønsker du å avslå invitasjonen? 


Avbryt — Avslå 


Figure 4.42: Edit Figure 4.43: Figure 4.44: Decline invitation 
profile info The invitation page modal in the mobile application 
in the mobile application in the mobile application 


The user can edit their profile information and delete their profile via settings. He/she can also 
set a new password if you wish to change this. If the user wishes to delete the profile, he/she will 
have to confirm that he/she approves that all information stored about him/her will be 

deleted and that he/she will lose access to all information in the application including his/her 
own registered data. 


On the invitation page, the user can manage their invitations and approve or decline them. If the 
user accepts an invitation, he/she will be added to the grazing group and he/she will have 
access to all registered data in the group. If the user wishes to decline the invitation, he/she 

will be asked to confirm this before the invitation is removed. 
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Slette tur 


Vil du slette denne turen? 


All info registrert vil bli slettet 


Avbryt — Slett 


Oppdalsgruppa 
Hanne Hove 31.5.2022 


Figure 4.45: Upload the trip page Figure 4.46: Modal to delete a locally saved 
in the mobile application trip 


To upload a trip after the internet connection is restored, the user must access the Local 
Trips page. Here, the trip will be displayed, and you have the opportunity to see details of the 
completed trip. Only one trip will be kept in memory at a time so a trip must be uploaded 
before the next trip can be started. You also have the option to delete the trip you have 
completed without uploading it. 
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4.6.1.5 Registration of inspection trips 


Oppdalsgruppa v 3 Oppdalsgruppa v 


Last ned kart Kart lastet ned 


Figure 4.47: Start page in the mobile application Figure 4.48: Start page for trip with map 
downloaded 


When a user has clicked on the Start new trip button , they will be navigated to New trip 

the screen. Here the user chooses which grazing group he/she should go for a walk. In addition, 
the user is shown a section of the map centered on the user's position which can be moved 

around and zoomed in. In order for users to be able to go for walks in areas that fall outside 
internet coverage, åa map section must be downloaded before the user starts the trip. By clicking on 
download map, the section of the map shown on the screen will be downloaded and written to local 
memory on the phone. When the map section has been downloaded, a button will appear in 

the bottom right corner that allows the user to proceed and start the new trip. 
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Legg til hendelse/notat 


Logg 


w Fullfør tur 


S] Avbryt tur 


Figure 4.49: The main page for a started trip in Figure 4.50: The menu during a started trip in 
the mobile application the mobile application 


Once the tour has started, you will be taken to the main page for the inspection tour. From 
here you can follow where you are on the map and plan your trip. In the top menu you will find 
two buttons. The menu icon on the left opens a slide-out menu that shows metadata about the 
trip, such as how long you have spent and how far you have moved. From here you can also 
register events or notes during the trip and complete or cancel the trip you are on. 


At the bottom right, you can again identify a button. This time it represents the opportunity to 
register a flock in the map when the overseer observes sheep 
during the trip. 
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Rovdyr Rovdyr 
Legg til hendelse/notat 


2:34 Jerv 
Description 


Jerv observert i skogkanten. 
2:35 Lam skadet 


2:36 Gjerdesjekk 


Klokkeslett 
2:17 


Jerv observert i skogkanten. 


Fullfør tur 


Avbryt tur 


Figure 4.51: Registration of an Figure 4.52: Events added to Figure 4.53: Editing an event 
event in the the log 


mobile application 


If the user wants to register an event, he/she will end up on the Register event screen. Here he/ 
she can enter data about the incident and register what type of incident it is. The options the user can 
choose from are: 


- Note - Injured animal 
- Dead animal - Predators 
- Other 


Each category has its own icon and color to make them easy to identify. When an event is saved, 
it appears in the log list in the menu. From here, users can remove or edit the events as needed. 


If the user wishes to edit an event, the event will appear on the same page and the user can edit the 
desired fields. In the picture above, pictures of the registered wolverine have been added. Events can 
also be deleted from the menu by confirming that you want to carry out this action in å modal. 
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Anna Fredriksen 
April 13, 2022 5:03:43 PM 


Anna Fredriksen 
May 21, 2022 5:50:05 PM 


Hans Karlsen 


May 28, 2022 7:01:49 PM 


Figure 4.54: Menu for selecting previous Figure 4.55: Previous trip shown in the map 
trips 


By clicking on the cogwheel in the top menu on the right, the user gets access to choose previous 
trips to show in the map. The previous trip is recorded, including where the supervisor saw sheep 
and where incidents were recorded along the way. This can be useful information if another 
supervisor is to investigate an incident that has been registered or if you want to see where the 
sheep were last seen when someone went for åa walk. 


If you no longer wish to see the trip on the map, you can click it away again in the menu. It 
is also possible to show several previous trips in the map at the same time. 
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Figure 4.56: Positioning of a flock in the Figure 4.57: Registration of a flock in the 
map map 


By clicking on the button at the bottom right, you are taken into registration mode for 
observed sheep. The button changes color to red to indicate that if you want to cancel the 
process, you can do this by clicking the button again. When the button is red, 

the user can freely place the herd he/she has observed in the map where the herd is. 


The flock marker looks like a sheep and is moveable until the user chooses to proceed with 
the registration. 


Once the user has placed the herd somewhere on the map, the button splits in two and 

gives the user the choice between canceling the registration of the herd and continuing 

in the registration flow. If the user chooses this, he/she will have the opportunity to register more 
details about the herd. 
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Registrer dyr Registrer dyr 


Grå sau: 0 Brun sau: 4 Grå sau: 0 Brun sau: 4 


Sort sau: 0 Grått lam: 0 Sort sau: 0 Grått lam: 0 


Brunt lam: 0 Sort lam: 0 Brunt lam: 0 


Figure 4.58: Binocular mode for registration Figure 4.59: Carrying out registration of sheep in 
of sheep binocular mode 


As the domain expert specified a need to register sheep, while the supervisor holds 
the binoculars up to his eyes due to difficulties in registering sheep flocks from a distance, 
two different ways of registering sheep were devised. 


Above you can see the final solution for registering sheep from a distance, binocular 

mode. If the herd the user registers is more than 30m away from the supervisor, 

binoculars mode will be displayed automatically when a herd is to be registered. In this mode, a 
large swipe button appears to make it easy for the user to add or remove sheep without 

looking at the screen. During registration on this page, a "Text to speech" tool is used to read 
out to the user which type of sheep he/she is currently registering. When the user adds or 
removes sheep, it is read out how many sheep of that type are now registered. In this way, the 
user can register sheep without looking at the screen and get feedback via the speaker on the 
phone. 


The user swipes right and left to record the number of sheep and down and up to navigate 
between different sheep types. As the user moves down the list, the currently registered sheep 
type will be highlighted in the list above the button. Once the user has made it through 

the flow, he/she will be able to swipe to 
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complete the flow. He/she will then be taken to manual mode where he/she can record more details 
about the sheep or complete the registration of the flock. 


Due to the fact that it is very difficult to identify details from a long distance, the binocular 

mode is limited to being able to record the number of sheep of each color, as this is often the only 
information that is possible to observe. Sometimes color can also be difficult to register. It is therefore 
also possible to only register a total number of sheep in binocular mode and then complete the 
registration by navigating to manual mode via the button in the right corner. 


3:27 % * 


Registrer dyr 


Sau - Grå 
TAG: 
Kommentar om flokken... Ukjent 
SLIPS: 
Ukjent 


Lam - Brun 
TAG: 
Ukjent 


Figure 4.60: Manual registration mode for Figure 4.61: Registration of animals in manual 
sheep mode 


If the supervisor is closer to a flock than 30m or has completed registration of sheep in binocular 
mode, he/she will be navigated to manual registration of a flock. If there are already registered 
sheep in binocular mode, the registered sheep will be displayed in the manual user interface. 
Here you have access to record the number of sheep of each type using the plus and minus 
buttons, in addition to being able to record more details about the sheep that have been 
observed. By clicking on Add more details, each sheep will be shown as an entity on the screen 
and you can register more details about each individual sheep. 
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The icon in the top corner of a sheep entity indicates what color the sheep is, but the 
information is also available in text format on the left side of the entity. 


You can always switch back to binocular mode by clicking on the eye icon in the top right 
corner of the screen. You can also cancel the registration of the herd by using the button in 
the top left corner. 


3:28 & (g vo 


Registrer dyr Registrer dyr 


OG Rød 
OQ vBlå 
0 Gul 


OG Havstein 


OG) Jahr 


Ukjent OG Grønn 


DLIKFD: 


Ukjent Ukjent 


Lam - Brun 
TAG: 
Ukjent 


Figure 4.63: Registration of tie color on 


Figure 4.62: Registration of an NG 


ear tag on a sheep 


When a supervisor is close enough to a sheep to observe more details about the sheep than the 

color of the wool, he/she will be able to record these on the sheep. Two of the relevant 

things to register are the color of the tie and the color of the ear tag. The color of the ear tag 

determines which farm in the grazing layer the sheep belongs to. In the dropdown menu, which 

is opened in the picture above on the left, you can see that in this pasture group there are three 

farms that each have a different color associated with them. It is also possible to select unknown, 

should å supervisor wish to use manual mode without having the opportunity to observe the mark of the sheep. 


In contrast to ear tags, which are found on all animals on open pasture, only adult sheep wear 
ties. The ties indicate how many lambs the sheep were released to pasture with and can be 
very relevant to record to observe whether lambs are missing in 
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the flock. The colors of the ties are predefined in the application and are based on standards set 
by Norsk Sau og Geit (NSG). The choice of tie can be seen in the picture above on the right. 
Here, too, it is possible to choose unknown in case the supervisor cannot observe the color of 


the tie. 


3:30 & * 


Registrer dyr 


Legg til kommentar 


Kommentar om sauen.. 


TAG: 


Figure 4.65: Å sheep marked as injured 


Figure 4.64: Add comment on a sheep 
and å comment on a lamb 


For each sheep or lamb registered, it is possible to add åa comment or mark the animal 

as damaged. If åa comment has been added to a sheep, an icon will appear next to the color mark 
to indicate that more information has been added to this animal. If the sheep is markedly 
damaged, the green damaged button will turn red, and å separate icon will be added to indicate 


the marking of the sheep next to the color mark. 
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Registrer dyr 
SAU 


GRÅ Q 1 
BRUN Q 1) 
SORT: Q [7 


Fullfør tur 


Er du sikker på at du vil fullføre 
turen? 


Tilbake Bekreft 


Kommentar om flokken 


Figure 4.66: Add an image of åa Figure 4.67: Group in map Figure 4.68: Complete 
herd by registration trip modal 


If the supervisor sees something abnormal or wants to add photos of the herd, this can be 
done by clicking the add photos button and selecting å photo from the phone's library. 

When å herd has been registered, you can save the herd and it will appear on the map as in 
Figure 4.67. The user is now free to add å new herd or event. 


To complete the trip, the user can open the trip menu again and use the complete trip button. 
This menu is shown in Figure 4.68. The user will get a modal where he/she must confirm 
that the trip is finished, before he/she is navigated to an overview of the completed 

trip where you can go through the data that has been recorded. 
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4.6.1.6 Completed trip 


& Hans Karlsen 


Beltegruppe * Oppdalsgruppa Tic 
pe 00:12:26 


Ant 


Flokker 


Flokk 1 
Flokk 2 


Flokk 3 


Vis alle flokkene 


Flokker Hendelser 1 
Flokk 1 niger 


Flokk 2 Vis alle hendelsene 


Figure 4.69: Overview of a Figure 4.70: Overview of å Figure 4.71: Overview of all 
completed completed registered herds 
inspection round inspection round 


When a trip has been completed or å user wants to see details of a previously 

completed trip either from Feed, via åa grazing group or before it is uploaded to the cloud 

the user will be navigated to the Tour screen. All data recorded throughout the completed 

trip is shown here. The user will be able to see who has carried out the trip, when it was carried out 
and for which grazing group. You can also see information about which trail was followed, where 
flocks were observed and where incidents were recorded. There is a separate panel for overall 
statistics about the trip. 


Under the statistics for the trip, there is an overview of all the flocks and events that were observed 
on the trip. The first three events and flocks that were registered are shown here. 

If the user wants to see all herds or events that were registered, he/she clicks on "Show all 

events" or "Show all herds". The overview of all herds and everyone 

events look confusingly similar. The list of all flocks is shown in Figure 4.71. 
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Antall sau Antall lam 
3 3 


Tittel Kategori 


Død Sau Dødt dyr 


Skader Klokkeslett 
1 19:10 


Bilder Klokkeslett 
1 19:13 
Kommentar 
Kommentar 


Død sau, litt ull 
mulig forårsaket av rovdyr 


Lam 2 


Brun * Jahr 


Lam 3 


Figure 4.72: Overview of a registered herd Figure 4.73: Overview of a registered event 


If the user wants to see more details about a registered herd or an event, he/she can 

click on the herd or the event. This will navigate the user to the flock or event page 
respectively. On this page, the user can see information about where the herd or event was 
registered on the inspection round, what data and statistics were recorded for the herd or 
event. By clicking on å sheep or lamb under a flock, 

the user can also see if there are notes on the sheep in question. If this exists, 

it will be marked with an icon next to the icon showing the animal's farm affiliation via a farm 
icon in the farm's colour. An icon will also appear here if the animal is marked as damaged 
during the trip. 


75 


Machine Translated by Google 


4.6.2 Web Application 

The web application offers the user functionality to create, manage and delete their user profile, the 
option to evaluate previously completed trips in the grazing groups and the option to generate 
reports over the grazing season. The web application functions to a large extent as an overview tool 
where you can explore the details of the trips completed that season. In the section below, this 
functionality will be presented in greater detail. 


4.6.2.1 Signup 


Figure 4.74: Login page in the web application 


When å user opens the web application, he/she will see the login screen of the 

application. All functionality in the application is behind logging in, as the data displayed is linked 

to users and registrations completed by them and others associated with grazing teams. Å user will 
have to use their email and password to log in. About 
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he/she does not have å user, he/she can create one by clicking on "Create new profile". 


Beiteweb 34 


Fortsett via den magiske linken sendt til deg på 
epost 


Figure 4.75: Creating a profile in the web application 


To create a new profile, the user's email must be verified. To do this, the system uses å magic 
link that is sent to the user's email. The user must click on the link in their email in order to 
continue the registration. This takes place in the same way as in the mobile application. 


Fullfør din registrering 


Din epost 


Fornavn 
Odd 


Etternavn 


Gjenta passord 


Figure 4.76: Completion of creating a profile in the web application 
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In order for the user to be able to use his new account, he/she must complete his/her profile. 

First name and last name are optional, but the password must be registered. If the user leaves 

the password field empty, if the passwords are not the same or if the password is Shorter than six 
characters, an error message will be displayed to the user. When the user is ready to complete his/ 
her profile, he/she can click on the complete button. 


4.6.2.2 Dashboard 


Dashbord 
Oppdalsgruppa 
Turer gått Døde sauer Rovdyr sett Skadde sau E 
Odd Larsen 3 2 2 2 
Medlemmer 
N Anno Fredriksen 
Årets turer æ pre 
Rapport 
OG 
1520 Fi = & Ha: 
13.5.2022 F 
å Odd tai 
Gårder 
ør me 
== Ha 


Profil 


Figure 4.77: The home page in the web application 


When a user is logged in, he/she will end up on the Dashboard side of the application. On this 
page, the user can browse through their grazing groups and previous seasons via the pull- 

down menu in the right-hand corner. At the top of the page, in the same way as in the mobile 

app, there is a statistics section that shows some of the most interesting figures for the grazing 
group so far in the selected season. This is to make it easy to get å general overview of what has 
happened in the group during the relevant season. Based on which group and season is selected, 
the "Tours of the year" section will also be populated with the completed trips in the group in that 
season. In Figure 4.77 you can see 3 trips. Each trip is described with the date carried out, who has 
carried out the trip and how many sheep were observed during the trip. In addition, each trip has 

an overview of events that have been registered on the trip. The icons to illustrate the events are 
the same as those used in the mobile application, so that they should be intuitive for the user and easy 
to relate to. To the right of the Dashboard you will find an overview of all members and farms 

in the group. On the left you will find a menu that makes it easy to navigate further in the application. 
To see more information about å completed trip, the user can click on the trip in question in the list. 


78 


Machine Translated by Google 


4.6.2.3 Tour overview 


Oppdalsgruppa 


Vis beitekvalitet i kart Tegnforidaring Hans Karlsen 
Flokker 


Registreringsposisjon  Hendelsesposisjon — Flokkposisjon 


Flokk I 
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Flokk 2 
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B Flokk 3 
Rapport 3 Sau 3 Lan 194003 
Hendelser 
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2 3 
Skadde dyr Klokkeslett 
) 19:05:44 
Saul | Farge: Grå Sau2 ØW Farge Brun 
G I slips Ukjent 3 I slips: Ukjent 
Q Å log: Ukjent å Tog: Ukjent 
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Figure 4.78: Overview of a completed trip in the web application 


When the user clicks on a trip in the Year's trips overview, he/she is navigated to a new page that 
shows an overview of the trip and registered details. The main focus on this page is the map 
which shows an overview of where the supervisor moved in the terrain. It also shows which 

flocks and events he/she has registered and where on the map they are located. A 

description of the different elements that can be observed in the map can be found above the 
map element. This includes the registration position of the supervisor when a flock was registered, 
flocks that were observed and events that were recorded. You also have the option to show 
grazing quality on the map and see an explanation of what the different markings of the 

grazing area mean. 


On the left you will find a list with an overview of registered flocks and events on the trip. 
Clicking on åa herd or event will display details of the herd or event at the bottom of the screen. 
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Oppdalsgruppa 


Vis beitekvalitet ikort Hans Karlsen 


£ R 
Tid vett 26.5.2002. 19:10:01 Nå 19:08:41 
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Figure 4.79: Info about a registered herd shown in the map 


If a user wants to see details about a herd in the map, it is possible to click on the herd and 
get some details about how many animals were registered in the herd and when it was 
observed. This can be useful when åa supervisor is planning å new trip or wants to understand 
the movement pattern of sheep on pasture. Å line is drawn between the registration 

position of the supervisor and the registered flock to better illustrate the connection 

between the positions and where the supervisor stood when he/she saw the sheep. 
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Figure 4.80: Overview of a herd registered on a trip in the web application 
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When a herd is selected it will appear at the bottom of the screen with all the details recorded about it. 
Each flock displays a statistics panel that presents some of the most interesting info to the user. Beyond 
this, each animal is shown as a separate card in the pack. Each sheep has data recorded about it that 
will appear on the cards. If the sheep is damaged, this will be marked with å red icon in the corner of 
the card and the text "WARNING! The lamb/sheep is marked as damaged' will be displayed. If there 


is any comment about a current sheep, this will also appear in the section below the damage text. 


In those cases where pictures have been taken of the flock, these will appear under the list of 
lambs and sheep. This is the same for events, an example of this is shown in figure 4.81. 


Registreringsposisjon 


LÅR 


Hendelsesposisjo 


n — Flokkposisjon 
Rousp 


Beskrivelse: 
Død sau, litt ull mulig forårsaket av rovdyr 


Hans Karlsen 


3 Lam 19:08:44 


Figure 4.81: Overview of an event registered on a trip in the web application 


If an event is selected, details recorded about it will appear at the bottom of the screen in the same 


way as a flock. The title and category are shown here, as well as a possible description of what has 


happened. If there are photos registered on the trip, these will be displayed at the bottom. 
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Figure 4.82: Overview of pasture quality in the map in the web application 


It is possible to visualize grazing quality in the map by using the toggle button. 

Data on pasture quality is only available in parts of Norway where this has been reported and 
is placed on top of the existing map as a separate map layer. The data is obtained from NIBIO 
(NIBIO, 2021). If the user wants a description of what the different colors in the grazing quality 
map mean, he/she can use the explanation button. 
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4.6.2.4 Report generation 


Rapport Rapport 
Beitegruppe Velg gruppe v Beitegruppe Oppdalsgruppa v 
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Sesong ' v Sesong 2022 v 
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Dashbord Dashbord 


Rapport Rapport 


Profil Profil 


Figure 4.83: Options for generating a report in Figure 4.84: Selected parameters for 
the web application generating a report in the web application 


When å user wants to generate a report on the carried out supervision, he/she will have options to 
choose which grazing group and which season he/she wants to generate a report for. 

Typically, this will be something a farmer does at the end of åa grazing season to submit 
documentation of completed supervision to the Environment Directorate. 

Both grazing group and season must be selected to generate a report. 
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Figure 4.85: First page of a generated report in the web application 
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Figure 4.86: Second page of a generated report in the web application 


When a user clicks on generate report, he/she will get a pdf file generated with all the 

information about the carried out inspection trips that is relevant for the Environment Directorate to 
acquire information about in order to be able to assess a compensation case for loss of sheep. The 
choice of which information is relevant is based on the farmers' association's guide for applications 
for compensation for loss of sheep (Norges Bondelag, 2020). First in the document becomes general 
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statistics and metadata about the grazing team and seasonal inspection trips presented. After this, 
the season's trips are presented with registered flocks and events. 


4.6.2.5 Profile 
Profil Profil 
Epost Oddlarsenøgmail.com Oddtorsen22gmoail.com ) 
Odd Larsen Odd Larsen EO E 
Fornavn Odd 
Fornavn Odd 
5 Etternavn Larsen IE 
Dasbbord ponoe Etternavn Larsen 
Passord Show 
Rapport Rapport Passord Show 
Oppdater profil 
Passord må ho 6 karakterer eller mer 
Logg ut Oppdater profil 
Logg ut 
= 
Profil Profi 
Figure 4.87: Overview of profile in Figure 4.88: Overview of error messages in 
the web application the profile section of the web application 


The profile page in the web application allows a user to change the information recorded about 
them. If the user tries to update their information with an invalid email or an invalid password, 
the user will receive an error message. 


4.7 Availability 


4.7.1 WCAG requirements 


WCAG or Web Content Accessibility Guidelines is an international standard for web 
development that contains criteria for developing web content for everyone. The criteria 

describe how to make web content more accessible to people with disabilities and 

help promote the development of content accessible to all 

(W3G Web Accessibility Initiative WAI, 2005). WCAG 2.0 was first developed in 2008 and in 
2013 it was adopted by Norwegian law that developed ICT solutions in Norway that target 
Norwegian users use the web/app as an important channel for offering services and have å 
website or app that is linked to the general function of the business must follow the WCAG standard 
and fulfill 35 of 61 success criteria (unsupervised) 

(Ministry of Administration, 2013). The rules are stricter for businesses in the public sector than in 
the private sector as the public sector must also follow EN 301 549 v3.2.1 which is åa 
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European standard which also includes the criteria in WCAG 2.1. This is not yet a requirement for 
private suppliers (unsupervised). The success criteria in the WCAG 2.0 standard are divided into 
three levels called A, AA and AAA. None of the requirements from category AAA are required by law 
for private suppliers in Norway, but it is positive if the solution still meets requirements in the 

AAA category (unsupervised). 


WCAG 2.0 does not have custom criteria for mobile applications, but it is specified that if the 
application needs internet access after it has been downloaded to the phone, the app is considered 
an online solution and it is therefore required that these are universally designed in the same way 
as web applications (unsupervised). Throughout the development process, the team has worked 

to follow the success criteria in the WCAG 2.0 standard and thus also to be in line with Norwegian 
law and focus on universal design and accessibility. 


Examples of the focus that has been kept on accessibility throughout the development period are that 
all elements that are interactive in the web application can be focused using keyboard 

navigation. In addition, all interaction elements are given a different color or design when a user 
hovers over them with the mouse pointer. In this way, it should be easy to see which elements 

are interactive and easier to navigate in the application. 


For the presentation of registered sheep in both the web application and the mobile application, 
emphasis has been placed on ensuring that the color of the sheep, the color of the tie or the ear 
tag is never only shown using colored icons or elements, but is always described with additional 
text. This is to make it easier for users who use screen readers, color blind users and other users 
who do not easily relate only to colors as an indication of information. 


4.7.2 Analysis of WCAG 2.0's success criteria 

The table below presents the first five success criteria in WCAG 2.0 and how well the developed 
system meets them. This is only an excerpt of the analysis and the full success criteria 

analysis can be seen in Appendix R. The table is color coded according to how well each success 
criterion is met. Green indicates completely fulfilled, yellow indicates that some deficiencies 

exist and red indicates that the requirement has not been met. In order for the system 

to have been launched, the criteria that are not met as of today must be improved. Through the 
success criteria analysis, the system was found to meet 30 of the success criteria, meet 2 of 

the success criteria partially and not meet 3 of the success criteria. The success criteria in the 
analysis are taken from Uutilsynet's presentation of the WCAG 2.0 standard (uutilsynet). 
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Success criteria analysis of WCAG 2.0 


Number Categdry — | riterion — | Degree offulfilment 


Non-textual 
content 


Audio only and 
video only 


Meaningful 


Table 4.9: Extract of the success criteria analysis of WCAG 2.0. Full analysis can be found in Appendix 
R. 
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The requirements that are currently not met consist of "Change of text size", "Skip over blocks" and "More 
ways to navigate". Changing the text size includes that the user must be able to enlarge the text up 

to 200% without the solution becoming challenging to use. The mobile application currently has some 
text fields that cannot withstand this. Skipping blocks is not relevant for the mobile application, but a 

user should be able to skip info to get to the most important information on a website. As of today, no 
such solutions have been entered into Beiteweb. Several ways to navigate ensure that the user can move 
around the system's hierarchy in more ways than with just one menu. As of today, this is not something 
that is possible in Beiteweb. 


The reason why these requirements have not been met is a focus on completing the solution within the 
time frames that follow the project. These bugs had to be fixed in order to launch the system as a complete 
solution. For a more complete description of all the success criteria including these three, see the 

full analysis in Appendix R. 


4.8 Development technology 
4.8.1 System architecture 
In order to make the system work and be available on several platforms, a system architecture was drawn 


up that should be easy to connect services to as needed. An outline of the architecture that has 
been prepared and how the various services are put together is presented below. 


BeiteMmaster 


Beiteweb webserver 


(heroku) 
Hente beitemeb applikasjon | | HTMU/Tavaseript 
V 
Hent/Sende beite-/brukerdata [ Hert/Sende beite-/brukerdata | | 
Beiteloggen = å N er | 
reel 2500 2500 arien 
på 5 —==> 
| TREN 7 | Backernd LIME YYN | 


Figure 4.89: System architecture for Beitemaster 


The system consists of three services; mobile application, backend service and web application. 
The grazing log 

Beiteloggen is a mobile application for Android and iOS developed in Flutter. 

Soup base 


Supabase acts as the backend for the BeiteMaster system, and is the primary source of data in both 
applications. The solution has automatically generated APIs based on the prepared data 

models in the database. Supabase builds on PostgresSQL and runs PostGREST, which makes the 

Postgres database available as a RESTful API (PostgREST) (PostgREST). Supabase also handles 

authentication in the applications by 
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use of Json Web Token (Supabase). JWT is an open industry standard for representing secure 
handling of exchanges between two parties (M. Jones, 2015). 


Grazing web 


Beitweb is an interactive SPA (single page application) with dynamic HTML rendering on the 
client side (client side rendering). 


Beiteweb is run in åa "dockerized" Node.js environment via an Express.js web server on Heroku, 
which is a PaaS (Platform as a Service) (Heroku; Heroku). The task of the web server is to make the 
Beiteweb application available on the internet. 


4.8.2 Mobile application / Grazing log 
This section describes the choices that were made around the development of the grazing log 
and how different elements have been used in the application. 


4.8.2.1 Choice of Language / Framework 


Native or cross platform 


At the start of the project, it was necessary to make some choices regarding which language the 
system should be coded in. The target group in the project is a relatively broad, comprehensive group, 
who do not have to comply with any guidelines in relation to the type of phone they own. 

This is for the benefit of, for example, a company that requires its employees to use iPhones. 

Based on this, the team started by doing research on which operating systems are most prevalent 

in the market today, so that the system could reach as many users as possible. 


StatCounter Global Stats 
Mobile Operating System Market Share Worldwide from May 2021 - May 2022 


p—G-me pr  ——Z 
——==0> ———e——6 
—CJe— 


O Android iOS O Samsung O KaiOS < Unknown Nokia Unknown O Windows Series 40 — Other (dotted) 


Figure 4.90: Statistics on mobile operating systems in the world 2021-2022 (Statcounter, 2022b) 


On å worldwide basis, there is a clear predominance of Android mobile phones with a market share 
of just over 70%, while Apple holds a share of approx. 28%. Other operating systems like this 
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as Samsung, KaiOs and Nokia hold market shares of a total of approx. 1% (Statcounter, 
2022b). Based on these numbers, Android OS still seems to dominate the market now. 

The user group for this project, on the other hand, is based in Norway and it could therefore be 
relevant to look at Norway's distribution separately, as all countries will have their own profile 
and we know that the technology market in Norway varies from, for example, India or China. 


StatCounter Global Stats 
Mobile Operating System Market Share Norway from May 2021 - May 2022 


Er —CQe— Ce 


iOS O Android O Samsung O Windows — Other (dotted) 


Figure 4.91: Distribution of mobile OS in Norway 2021-2022 (Statcounter, 2022a) 


By examining data from the Norwegian market presented in the graph above, we see that iOS 
generally holds åa much higher market share in Norway than in the world on a general basis. In 
Norway, IOS has a market share equivalent to 59%, while Android has around 40% here. Other 
operating systems account for slightly less than 1% of the market (Statcounter, 2022a). 


Based on the market share survey presented, the team wanted to offer a solution that supports 
both iOS and Android operating systems equally. This would ensure that the largest possible part 
of the system's target group is reached and that as many users as possible can use the system. As 
the proportion of other operating systems is as low as less than 1% both on åa Norwegian basis and 
in the world, the mobile application will not initially be developed with these users in mind. The 
team therefore continued in the process with the goal of developing for the OS and Android 
platforms. 


Based on this conclusion, the team investigated which technologies could be most relevant to 
cover both platforms effectively. Android and iOS offer Java/Kotlin 

and Swift respectively as development technologies for "native" (platform-specific) development 
solutions for their platforms (developers, Android; developers, Apple). If you choose to use one of 
these, you end up with solutions that only run on one of the platforms. An alternative would be to 
code the solution in both languages so that you end up with two native solutions, one that can run 
on Android and one that can run on iOS. However, this is very time-consuming and as the team 
only consisted of two 
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developers, this would be an almost impossible task to carry out during the limited project 
period. The team therefore chose to move away from the idea of developing native solutions and 
focus on technology that allowed the development of one code base for both platforms. 


Developing a solution for both Android and iOS platforms that is based on a single codebase is 
called cross-platform development and has both advantages and disadvantages compared to 
native development. Some of the advantages and disadvantages of cross-platform development 
vs native development are presented in the table below. 


Cross-platform development 


Cons 
VEN a arger manet 


[Reducedworkoad [0 
[Gonsisent functionality aæross platforms — | 


Table 4.10: Advantages and disadvantages of cross-platform development compared to native 
development (Marchuk) (Merixstudio, 2022) 


As has already been discussed in previous sections, you have the opportunity to reach a larger 
market by using cross-platform development as you develop for both platforms 

simultaneous. In addition, it can be an advantage to only have one codebase for the developers to 
deal with when it comes to development time and deployment. The development time will be 
shortened as the developers only need to code the solution once, and although they will still 

need to take into account OS specific functionality, they will be able to deal with one language and 
the same developers will be able to carry out changes for both platforms 

(Merix studio, 2022). 


Another aspect of the benefits of a common codebase is that as the same codebase is 
deployed to production for both platforms, both "versions" of the application will have the same 
functionality at all times. There will thus rarely be deviations between functionality found in the 
Android and iOS versions or different ways of performing an action based on which OS you use 
(Merixstudio, 2022). 


On the other hand, there are also disadvantages to cross-platform development. The biggest of 
these, which is often one of the most discussed drawbacks, is the application's performance. Due 
to the necessity for an additional abstraction layer that abstracts away the underlying 
platform-specific elements, cross-platform applications will often have somewhat poorer 
performance than native applications. This is because native solutions 

interacts directly with the operating system (Merixstudio, 2022) (Marchuk). In addition to this, 
with cross-platform development it can be a challenge to design and use platform-specific design 
and standards defined by the operating systems. There are different navigation patterns and 
behavior in Android and iOS that developers have to deal with specifically in a cross-platform 
application, but which they don't necessarily have to think about in native development (Marchuk) 
(Merixstudio, 2022). 


When developing cross-platform, it is important to note that not all APIs that are available 
for each native platform are available through the cross-platform language's 
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platform. This means that certain functionalities delivered to Android or IOS may not be available 
when using åa cross-platform language as this is maintained and delivered by the surrounding 
environment or the developers of the language (Marchuk). Finally, it is relevant to discuss that 
native solutions can scale better than cross-platform solutions, 

depending on how much system resources they use and that a native solution often has better 
resource use on the basis of the extra layer of abstraction in the cross- 

platform solutions (Marchuk). 


For this project, the team considered that the advantages of cross-platform development clearly 
outweighed the disadvantages in terms of time aspect, manageability and reaching as many as 
possible in the target group. 


What å cross platform language 


There are many cross-platform options out there, but as the team was concerned with optimizing 
performance as much as possible, none of the cross-platform solutions that act as wrappers for 
web applications were relevant. This shortened the relevant list considerably and the team 

came to the conclusion early on that the choice was between three frameworks, all of which are 
compiled and run on the mobile device. The three options were React Native, Flutter and Xamarin. 


React Native 


React Native is a framework developed and maintained by Meta. lt is based on JavaScript and 
React, which is a library for user interface development 

(ReactNative). Although React Native is written in JavaScript, the components are rendered as 
native platform components. This contributes to a native feeling in a cross-platform 

app and you can use many of the same APIs that native apps do (ReactNative). 


Flutter 


Flutter is a framework developed and maintained by Google. Flutter is written in Dart, which is 
Google's own object-oriented programming language. Flutter code is compiled into machine code 
for mobile applications and JavaScript for web solutions for a fast and good experience in 

line with native applications (Flutter). 


Xamarin 


Xamarin is an extension of Microsoft's .NET platform with tools and libraries designed for 
developing mobile, device and Windows applications. Xamarin code 

compiles for native performance and gives developers access to the platform's underlying APIs 
(Microsoft). 


To better illustrate and compare the various options, the developers prepared a 
matrix. 
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Documentation and API 
Framework Crossi platform Map support Mee Experience 


Android 
(Java/Kotlin) 


Swift/Objective-C 
React Native 
Flutter 


Xamarin 


Table 4.11: Matrix for choosing an application framework 


It turned out early on that all the relevant solutions offered the functionality that was necessary for development in the project. 
Based on this, great emphasis was finally placed on what the developers in the team already knew and what they were interested in 
learning more about. None of the developers were familiar with the .NET platform from before. In addition to this, Xamarin 
applications are built together with several of the included libraries used in the project and thus the applications tend to have 


to be further optimized than other alternatives (Altexsoft, 2020). Based on this, the team opted out of this option. 


The team thus had the choice between React Native and Flutter. Both developers in the team had experience with Flutter, but only 
experience with React through web development. Based on the fact that both were interested in learning more about Flutter 


development and improving their knowledge and abilities in this area, the choice ultimately fell on Flutter. 


Flutter currently supports Android API versions back to version 19 (Flutter). This covers the requirement laid down in the 

technical requirement specification that Android versions back to Queen Cake must be supported as Queen Cake currently runs API 
version 29 (developers, Andrioid). In addition, Flutter supports versions of OS back to iOS 9, which also meets the stated 

requirement for coverage of OS versions back to version 12, which is the latest maintained by Apple in terms of security (Flutter) 
(Apple). In addition to this, the team made sure that the other technical specifications set out in the technical requirements specification 


were covered by the APIs and functionality Flutter offers as of today. 


For a full overview of the technical requirements specification see appendix B. 


4.8.2.2 Development: Flutter and Dart 

Flutter, which is Google's Ul library for cross-platform development, acts as a framework for Ul components called 

widgets. Widgets come pre-defined from Flutter as they would in other Ul libraries, or they can be created by the developers 
themselves. 

The logic that is written in and around widgets to achieve the desired functionality is written in Dart, Google's own object-oriented 
programming language. Dart was not originally developed for Flutter, but has become one of the most important building blocks in 


their cross-platform landscape (Flutter). 
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A widget works in practice as a small part of an application that is combined with other widgets 

to form a complete solution. Based on this modular structure, it is beneficial and good 

practice to prepare as generic widgets as possible so that they can be reused in several places in 
the application. In this way, you can use the code several times and it is not necessary to 
produce something new every time you need å component. 


Throughout the project, the developers have both used existing widgets and built their own. An 
example of this is the buttons on the profile page in the application where the team has defined 
its own format for the interaction elements as this is not something offered directly from 

Flutter's library. Here, a ListTile is surrounded by a "Material component" which has been 
assigned its own design elements such as elevation and border radius. Inside the ListTile you will 
again find two icon widgets and a Text widget. This pattern can be found again for all interaction 
elements in the application. 


å Hanne Hove 
2 Innstillinger > 
t Last opp ny tur på 
M Mine invitasjoner > 
Logg ut 


Figure 4.92: Illustration of self-developed widget element 


Dart is Google's own object-oriented programming language and is used together with Flutter 

to write logic for Widget functionality. Dart and Flutter are closely linked, 

and it can be somewhat difficult to distinguish what is "Backend" and what is "Frontend" in terms 
of structure. There is, however, some logic functionality that is clearly separated from the 
Widget Trees, such as data models, data retrieval and storage functionality. 


State management 


For state management in applications, Flutter uses something called providers. 

Providers are placed "around" relevant widgets to "provide" them with a separate "state" that can 
be accessed by all widgets in the widget tree below the widget that is a direct child of the 
Provider. When this top Widget is removed from the "active stack" in the application (That is, you 
navigate away from the widget) the widget will be "unmounted", which will also "Dispose" the 
relevant provider. When this happens, the provider's state will be removed and you will start over 
with a fresh provider the next time the relevant component is "mounted" again (by, for example, 
navigating to it). An example of this in this project is "Register Flock provider", which is 
instantiated every time a flock is to be registered on åa 
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turn, and which are then "dismounted" and started again for the next flock. In this way, it is 
guaranteed that the user always starts with a "clean" state. 


You can also have global providers in the application that maintain global state. An 

example of this in this project is the "Profile provider", which keeps track of which user is logged 
into the entire application and thus means that you have access to user information 

throughout the entire application flow. This is useful both on the profile page and for retrieving 
the relevant data for the user on the Pasture Group and Activity screen. 


Local storage 


When a trip is carried out in the mobile application, there is a possibility that the user is outside the 
coverage area of the mobile network. In order for the user to be able to safely carry out 

a trip without risking loss of network and thus data, a solution has been implemented 

that saves the trip locally until the user gets the internet back and can safely upload the trip to 
the database. During the trip itself, the trip details are stored in several state providers in the 
application. They keep all data about the trip and are continuously updated during the 
implementation. When the trip ends, the data is written to the local file storage system for 
preservation until the user wants to upload the data to the cloud. When the user uploads the data 
successfully, the local copy in the file storage system is deleted. 

In order for this to be carried out, all data is serialized between json format and data 

objects when reading and writing files. Separate methods and functions have been 

written for this. In addition, supplementary tests have been written to ensure that functionality 
works as intended. This is written more about in "Testing". 


4.8.3 Web application / Beiteweb 
This section describes the choices that were made around the development of Beiteweb 
and how different elements have been used in the application. 


4.8.3.1 Choice of Language / Framework 

When choosing the language and framework for the web application, heavy emphasis was 
placed on the previous experience of the developers in the team, in addition to the trends in the 
current market. Both developers in the team are most comfortable with JavaScript as åa 
development language when it comes to web development. It was therefore decided that the 
framework they wanted to use should be a JavaScript framework, which eliminated solutions 
such as Django for Python and the like. When it comes to frameworks that use JavaScript as åa 
development language, there are three that are most used. These three are React, Vue and 
Angular. 


The graph below shows the number of downloads of each framework over the past year via the 
Node package manager, a package management tool. 
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Figure 4.93: Statistics of the most downloaded frameworks for web development at Node package 
manager (NPM, 2022) 


Both developers on the team had experience with both React and Vue as 

development frameworks, but after evaluating the graph above, the team decided to start with 
React. This is both because both had experience with this framework and also because it is åa 
well-supported framework that currently really stands out in terms of popularity among 
developers (NPM, 2022). 


4.8.3.2 Frontend: React — Typescript 

Frontend, the solution was developed with React, TypeScript and Redux. Typescript was chosen 
in favor of JavaScript as it provides opportunities to give types to elements and objects so that it 
is easier to detect errors during development (Typescript). 


For state management, Redux was used together with the Redux toolkit. Redux gives 
applications the ability to handle a global state for the application so that several components 
that are separated from each other in terms of code all have access to the same state- 
dependent data and can be redrawn on the screen based on a "single source of 

truth" (Redux). In addition, RTK (Redux toolkit) was used to simplify the setup of the 

Redux store (the organization of data in the Redux container that holds global data), and to 
streamline data acquisition from APIs. With the help of RTK Query, data is retrieved directly from 
APIs and placed directly in the Redux store ready for use in the components of the entire application 
instead of a component being responsible for obtaining data that is then placed in the 

Redux store. This helps to make the data collection more efficient both by retrieving data when 
loading without being dependent on å single component, in addition to the data being cached, so 
that data is not updated unnecessarily if nothing has changed in the content since the last 
loading (ReduxToolkit). 
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An example of using Redux and RTK Query in the web application is on the dashboard where data 
is retrieved through APIs from Supabase when a user accesses the page. The response from the 
API is transformed via RTK Query into another format to make it easier to find trips completed per 
grazing group and is placed in the Redux store. When a user selects which grazing group he/she 
wants to see data for, the selected grazing group is placed in the Redux store and all data can be 
easily retrieved from RTK Query via its own hooks. When a user clicks on a trip to see more data 
about it, this information is already available in the Redux store and the page is made available 
immediately without further loading time. When the user navigates back to the dashboard, the 
previously selected pasture group will still be selected as it was set in the Redux store earlier. In 
this way, state can be preserved between page navigation and give the user åa more 

holistic experience without the feeling of having to "start over" every time he/she comes to 

the dashboard. 


4.8.3.3 Backend 

To offer data and authentication to the web application and then to "serve" 

the online web application uses two backend solutions. The main solution for data and 
authentication lies with Supabase as shown in "System architecture" and this is discussed further 
in the "Database" section. 


To "host" the web application, a web server has been developed which is hosted on Heroku. 

The web server has been developed with Node.js, Javascript and Express.js where all hits on 
www.beiteweb.heroukapp.com return the web application. The Express server is set up with 
middleware provided by Helmet.js which helps secure the solution against various 

security attacks such as Cross-Site Request Forgery and Cross-Site Scripting. 

The team has chosen this solution for delivering the web application because Heroku as a 

PaasS (Platform as a service) has a user-friendly interface for setting up different hosting services. In 
addition, they offer easy integration towards 

the source code base on Github, which helps to ensure that the set up CI/CD (Continuous 
Integration and deployment) configuration works well, and continuously ensures that the latest 
version of the code base is available on Heroku. More about CI/CD is documented in "Continuous 
integration and deployment". 


4.8.4 Database: Supabase (BaaS) 

The mobile application and the web application share a common database where all information 
stored in the system is organised. Supabase was originally developed as an alternative to Firebase, 
which is Google's "Backend as a service" platform (Supabase). The main difference between 
Firebase and Supabase database-wise is that Firebase offers a NoSQL solution, which means 

that the database structure is not organized with tables as traditional databases are, but 

rather in collections and document structures, while Supabase is based on the Postgres structure 
which is built up with database tables in the traditional way show 

(Firebase) (Supabase). As the team has experience working with SQL databases and 

identified that the data that was to be stored through the project had clear relationships to each 
other to the highest extent, they considered it natural to use an SQL-based database alternative. 

In addition, the team wanted to use a "Backend as a service" solution as this makes it easier to 
secure data transfer, simplifies and secures login and authentication processes and reduces the risk 
of server weaknesses (CloudFlare). 

Supabase was therefore a natural choice that offered the functionality the team wanted. 


"Backend as a service" or BaaS describes solutions where the supplier delivers software 
services that traditionally take place on åa server to developers through 
APIs, such as user authentication, database management, cloud storage and hosting 
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(Cloud Flare). For both the web application and the mobile application, Supabase was used to 
handle login and authentication of users, secure storage of user data and 
secure storage of user-registered data. 


As Supabase uses Postgrass internally for organizing data and making queries, the 
database allows users to set up their own tables and link them together through foreign 
keys as in a traditional SQL database. The figure below shows the prepared database diagram for 


the system. 
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Farm 
PK | id 
name 
color 
FK | grazing group id 


Member Profiles 
GrazingGroup 
sl LE TE 
KER ak ve 
pending first name 
FK | user id last name 
FK | grazing group id picture 


Trip 


PK | id 
start time 
end time description 
distance category 
FK | grazing group id trip id 
FK | user id waypoint id 
eo 


Location Waypoint 


PK | ld [F] 


FK | waypoint id timestamp 


FK | trip id latitude 


longitude 


trip id 


Image 
Q id PK | id 
color img url 
Flock 
tie color note FK event id 
PK | id fi 
note is injured FK | flock id 
total sheep 


is injured flock id 


note 
flock id 


farm id 


FK | trip id 


farm id 
FK register position id 


FK | flock position id 


Figure 4.94: UML diagram for the system 


Based on the prepared diagram showing the connection between the various tables and entities 
in the database, the tables were created in Supabase. The figure below 
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shows an extract from the Grazing group table with several entities in addition to an overview of the 
different tables in the database. 


id created at name 


Nowkalle 04b064c1-5496-4c5d-96e6-3c03508!8ab3 2022-03-13 23:06:59.792803+00 Hedmarksgjengen 
06ab96:8-6baf-4e0e-9c2e-94021d0bed83 2022-03-13 23:12:54.049448+00 Østfold gjengen 
d711d633-bfb7-47de-b79e-1dbf8f313d6d 2022-05-28 14:05:41.585651+00 Oppdalsgruppa 


flock 


grazingGroup 


Figure 4.95: Overview of the tables in the Supabase database 


Based on the tables and thus the data models that have been defined, Supabase will generate 
endpoints for retrieving, inserting and updating data that can be used both in Dart and in JavaScript. 
In this way, both apps interact seamlessly with the database and you will see changes reflected 

in one if you update the database from the other. 


For entities that do not have primitive data types, such as media files, Supabase uses "Storage 
buckets" for storage. This means that a separate file hierarchy must be defined 

programmatically when the applications want to save the images so that they can be found again in 
a logical way. In this system, the team chose to create a separate "Storage bucket" called 

"Trips", then subfolders are created for each trip based on the trip's unique ID. In this folder there 
are again several folders based on which event or group the images belong to. The folders are 
named based on the event or batch ID. The image below illustrates the layout of such folders in 
"Storage buckets". 
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BE 18724416-7057-404a-s8cd 3 43212600-0321-455c-9bld 


3 43218600 0321-455c-bld 


Figure 4.96: Overview of a "Storage bucket" for an event on a trip 


Based on who owns the image or who are the administrators and members of the grazing 
groups, separate rules have been set up for who can read or delete images from the database. 


When a user wants to create a profile in one of the applications, an entity is created in the 
"Authentication" table in Supabase, which is a Supabase-generated table that holds 

e-mail, creation time, last login time and user ID. At the same time, an entity with the same ID and 
email is created in the "profiles" table, which holds this in addition to other data the user can change 
himself, such as first name, last name and profile picture URL. When the user is first sent the 
verification link when creating a profile, the user will be flagged in the database as "not verified" 
and no user data other than email will be set in the "profiles" table. When the user clicks on the 
login link they were sent, the system will perceive that the user has been flagged and ask the user 
to fill in further details to complete their profile with the details they want in addition to the desired 
password. When this has been completed, the verification flag is removed from the user and the 
account is ready for use. 


4.8.5 External APIs and Libraries 

In both the mobile and web application, several different libraries and APIs have been used to solve 
the requirements of the applications. In this section, some of those that are considered most 
important for fulfilling the solution's requirements are highlighted. 


4.8.5.1 Mobile Application 

One of the most essential functions of the mobile application is the map that is used when the 

user is on a trip. The requirements for the map include several interactive and customized solutions 
such as registration of animals and events, and download. Because of this, it has been important 
to use a library that has allowed its own implementations beyond just showing å map to the user 
with a position. The Flutter Map library has å good and flexible API to work with and has allowed 
adding all the functionality that has been needed. This is 

functionality such as different map sources, map projection, map layers, motion detection and 
position data (Fleaflet.dev, 2022). It became clear early on through conversations with the 

domain expert that he considered the Map Agency the best alternative as a map source, 

as they have complementary information and offer good detailed maps of most of Norway. This has 
therefore been chosen for implementation in the application. 
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colors, themes, component styles, and so on, can easily be swapped out as needed. Several of 
the chakra components have been modified or built upon to meet the application's needs. 


4.8.6 Technical implementations 
This section describes particularly noteworthy implementations in the applications that are critical 
for the system's operation and delivery of services. 


4.8.6.1 Downloading maps 

An important requirement for the system was that the map section used for an inspection 

trip is available at all times, during the entire trip. As users are in danger of losing 

mobile coverage on inspection trips and therefore also access to updated map sections, a solution 
has been developed to download the map section for the area before the trip is to be carried out. 
This is done by all map tiles in the area within the map window on the "start trip" screen, 

is downloaded and stored locally on the phone before the trip is started. When the trip is started, a 
map section is retrieved using an "online-first" strategy with fallback to the cache, which means 
that as long as the phone has mobile coverage, it will use the internet to load map tiles and when 
the phone loses internet, the map tiles are retrieved from å downloaded version on the phone. 


To achieve this implementation, the Flutter libraries Flutter Map (Fleaflet.dev, 2022) and Flutter 
Map Tile Caching (jaffaketchup.dev, 2022) have been used. Flutter Map has been developed 
based on Leaflet, which is the same map solution used in the web application, which 

makes the use of maps relatively similar in both solutions and thus more intuitive (Fleaflet.dev, 
2022). 


4.8.6.2 Design patterns 

With a perspective on code and code quality, the team has been concerned with 

using conventional design patterns to solve different problems and tasks. The team has seen this 
as important to follow DRY (Do Not Repeat Yourself) and to minimize bugs and simplify unit 
tests (Andrew Hunt, 1999). For example, singleton patterns are used to access the Supabase 
database client instance in the mobile application. This 

is done to ensure that there are no more database connections around the application 

at the same time, which in turn ensures that the solution is thread safe. 


The team has also used "builder patterns" in several places in the mobile application as this has å 
good implementation in Dart through a language tool called "Cascade" 
(Darts). That is, instead of having functions that return the "This" keyword, which is typically done in 


Java, in Dart you can instead use a ".." notation for each method call. 


4.8.6.3 Position data 

To access location data in the mobile application, a geolocation library is used that uses the 
underlying integrated location providers on Android and iOS (baseflow.com). Here, the 

sensor data in the phone is used to find position and movement through the accelerometer and 
magnetometer. Position data is updated continuously, but in order to limit the amount of data that is 
stored, only points are stored where the change in position amounts to more than ten meters 

or at a time interval of two minutes. These are parameters that have been requested and 

proposed by Professor Hvasshovd. 


An important implementation point for location data is that this service updates and stores data 
continuously even if the phone is in locked mode. This means that when the screen is turned off, 
or the home screen is not available, or if you exit the app while a trip is in progress, for example 
by opening another app or moving to the home screen 
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data will still be recorded. This is important so that the trip is registered correctly and that the user 
can use the phone for other things during an active trip. 


4.8.7 Continuous integration and deployment 

CI/CD (Continuous integration and deployment) has been used in the project for both the web and 
mobile application. This means that code supplied to the project is automatically tested and 

built before it is integrated into the codebase and that when the tests and the build have been 
completed without errors, the code is sent out for production. 


To ensure that the Flutter application works after new implementations, a Flutter CI action is run 
on each pull request to the repository. This action builds and runs all the tests in the codebase to 
detect if the code cannot be built, or if something no longer matches the tests written. This tool 
helps to ensure that the codebase is always in å working state after new additions. Below is an 
excerpt of the set up integration which ensures that the tests are run. 


tt flutter.yml 
name: Flutter Test 


on: 
push: 
branches: [main] 
pull request: 
branches: [main] 
jobs: 
test: 
runs-on: ubuntu-latest 
steps: 
- uses: actions/checkoutv3 
- name: Flutter action 
uses: subosito/flutter-actionÆv2 


- run: flutter pub get 
- run: flutter test 


For the web application, an action has been set up that ensures that all new code additions that 
pass automatic tests and builds are sent out to production. This means that Beiteweb, 

which is available openly under Heroku's domain, will be updated with the latest changes at all 
times. 


4.9 Security 


As the developed application collects user data and stores data specifically for users, security 
is an important aspect. Throughout the project, there has been a focus on safety throughout 
the development and planning period. 

4.9.1GDPR 


GDPR (General Data Protection Regulation) is an adopted regulation introduced for all countries 
with EU membership or which follow EU standards, which has been in effect since 25 May 
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2018 (Consulting). Act on the follow-up of EU regulations in Norway was adopted on 15 
June 2018 (Regjeringen, 2019). The law states that the collection of personal data must 
take place as necessary or with the consent of the user. In addition, the user must be able 
to have their data deleted as they wish by both being able to delete their profile, but also by 
contacting the company/collector and having their registered data removed from their 
systems (Regjeringen, 2019). 


In order to meet these requirements, all users who wish to use the system must approve user 
terms before they can create a profile. When the collection of personal data is based on 

the user's consent, according to the law, the user always has the opportunity to withdraw this 
consent. In addition, it is required that the user is over 13 years of age to be able to give 

such consent to the collection of data. There are also a number of other factors that the user must 
be informed about before they consent to data collection, which are specified in the Personal 
Data Act (Ministry of Emergency Management, 2018). The figure below shows the prepared 

user terms and conditions that must be approved. 


Personvernerklæring 


Personopplysninger vi samler inn 
og behandler 

Grunnleggende informasjon 

Navn. 

Kontaktinformasjon 

E-postadresse. 

Brukeraktivitet 

Oppsynsturer, beltelag, gårder og 
posisjon. 

Brukerhistorikk 

Historikk av oppsynsturer, beitelag og 
posisjon. 

Cookies 

Informasjonskapsler blir brukt for å 
håndtere innlogging, kryptert passord og 
for brukerdefinerte innstillinger i 
applikasjonene. Informasjonskapslene 
har en standard levetid på 60 minutter, 
men utvides ved kontinuerlig bruk av 
tjenestene. 


Hvordan vi bruker 

personopplysningene 

Grunnlag for databehandling Password 
Data vil bli behandlet basert på samtykke 

fra bruker av applikasjonen. Din 

informasjon vil bli samlet inn, organisert, 

lagret og brukt i applikasjonen i 


Slett profil 


Figure 4.98: Terms of use and the option to delete å profile 


The user data stored in this application includes email, first name, last name, profile picture 
and password. First name, last name and profile picture are optional and not required by the 
user to register. Email and password are both required for creating a profile. In addition to the 
information that is directly identifying the user, completed supervision visits the user has 
completed and their membership in different groups are stored. 

As the application is based on the user's consent for the collection and storage of information, 
provision has been made for the user to withdraw their consent themselves by having the 
option to delete their profile. 
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4.9.2 Information security 

Throughout the development of the application, there has been an overall focus on security and 
the applications have been developed with regard to OWASP's top 10 list of 

security risks (OWASP, 2021). Not all risks will be discussed in this section. 


User access to the database 


As Supabase makes use of Postgres, there is also functionality for RLS (Row level 

security). RLS makes it possible to determine who has access to view, edit and delete rows in a 
database (Microsoft, 2021). This means that there are reduced rules in the database to 

ensure that only users who are authorized to see the information get access to retrieve 

the information in question. 

The rules are reduced in the database via the creation of "Policies" which, for example, only 
allow users who are part of a grazing group to have access to retrieve the trips registered in 

the group. 


XSS and SQL injections 


SQL (Structured Query Language) injections are a way to destroy or gain access to data in åa 
database by writing SQL queries into input fields in the application which will then be executed in 
the database and return data that should not be accessible to the user (W3Schools ). This could 
also result in data being changed or the database being deleted, which would be disastrous 

for the solution. Supabase uses a Postgres database that uses SQL as query language and it 

is therefore of interest to investigate how well it is protected against this. In the system, all 
interactions with the database are done through Supabase's api's, which parameterize all queries 
that are carried out. This means that the users" input is never sent directly to the database in the 
form in which they were written, which also prevents SQL injections from being performed 
(Chavez, 2021). 


XSS (Cross site scripting) attacks are also a form of injection attack where an attacker writes code 
into input fields that are later stored in the database. When the information is retrieved from 

the database at a later time, the code will be executed in the online time where the information 
retrieved from the database should be displayed (KirstenS). As no data in the web 

application is dynamically generated where HTML elements have to be rendered from 

acquired data, React automatically ensures that all data displayed from the database is converted 
to String format. In this way, any scripts that may have been stored in the database are not 
executed (StackHawk, 2021). 


4.10 Testing 


Throughout and at the end of the project, several technical tests were written and run which 
helped to verify functionality both in terms of code and overall. In the code, unit tests were 
prepared to test data models, mapping of objects and business logic. 

At the end of the project, a system test was carried out to evaluate how well the system 
met the requirements that had been drawn up before the start of development. 
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One of the main reasons why tests have played a central role throughout the development process 
is that the project has used a BaasS. To ensure that this could be connected without 

accompanying problems, it was important to verify the functionality of the business logic and data 
models. This test writing process has meant that certain functionalities have been developed through 
test-driven development, which means that all tests were written before the implementation of 
functionality. This has helped to ensure that connection to BaaS has been very flexible. In addition, 
user input is an important and central element in the application, which means that it 

has been important to ensure that the solutions deliver results that match the intended purposes of 
the functionalities. 


4.10.1 Unit Testing 


Both Black-Box and White-Box unit tests have been written for several parts of the system. 

The Black-Box tests test the functionality through the interface without knowing anything about the 
underlying coded functionality. The goal is to test how typical extreme or rare situations are handled, 
a typical example is a function that takes in two integers and this is tested by sending in INT MAX 


and INT MIN, and then evaluate how the code handles this. The vast majority of tests, on the other 
hand, are written in a White-Box sense where the purpose is to test functionality with underlying 


knowledge of how the code is implemented with the aim of testing the different outcomes the 

code can have and verifying that the expected result is reached. An example of such a test is testing 
the creation of an image object belonging to a custom image class, where the class can 

hold either a url or a file. The implementation of such a test is shown in the figure below. 


test("Create an image with provided url successfully", () I 
Image img = Image(url: "testurl", file: null); 
expect(img.url, "testurl"); 
expect(img.file, null); 

Ds 

test("Create an image with provided file successfully", () ( 
XFile testFfile = XFile.fromData(base64Decode("sourcesz")); 
Image img = Image(url: null, file: testFile); 
expect(img.file, testFile); 
expect(img.url, null); 


21 "Create an image without providing an url or a file " 
"should fail and throw an assertionerror", () ( 
expect(() ( 
Image(url: null, file: null); 
), throwsAssertionError); 


DE 


test("Create an image with url and file should fail and throw assertionerror", 
OG 
expect(() I 
Image(url: "testurl", file: XFile.fromData(base64Decode("sourcesz"))); 
), throwsAssertionError); 


): 


Figure 4.99: Unit test Image 
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4.10.2 System testing Based 

on performance targets and the functional and non-functional requirements that were determined 
early in the project, a system test was prepared to examine how well the system fulfills them. The testing 

was carried out as Black-Box testing where the code was not the focus, but the user's experience and 
performance of tasks were evaluated. Below is an overview of the first 5 functional requirements for the mobile 
and web application in addition to the non-functional requirements. The complete test with all results can 

be found in Appendix S. 


| =m [me [om — 


Å user must be able to 

create a profile to use the 

system 

Å user with åa profile must be 

able to access the system with 

their email and password | 

A user must be able to delete As of today, the user is deleted 

their profile with all relevant data they 
have registered. Optimally, the 
user can be deleted, 
and the supervision 
data can be kept anonymised 


Å user must be able to see the 
most recent trips that have been 


Å user must be able to 

create a profile to use the 

system 

Å user with a profile must be 

able to access the system with 

their email and password 

A user must be able to delete As of today, the user is deleted 

their profile with all relevant data they 
have registered. Optimally, the 
user can be deleted, 
and the supervision 
data can be kept anonymised 


Å user must be able to change 
their profile information 


A user must be able to see 


details of the trip after 
completing the trip 
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Not functional 


Faster to generate Measured 
reports than manual creation E through comparison test 


Easier to find | Measured by conversation 


grazing data/animal data about with a domain expert 
your farm than without the system 
Fast to load data Under 1 second for 
loading data and 
displaying all pages in 
| the application 
Follows current laws and 
regulations 
regarding privacy and GDPR 
Storage takes less than 2 
Data is stored securely and seconds locally and less than 10 
efficiently seconds to the cloud. 


Table 4.12: Overview of some of the test criteria in the system test 
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5 Results 
5.1 Final user test of the solution 


At the end of the development period, a final user test of the solution was carried out to evaluate 
whether the users perceived the system as usable, sufficient and fulfilled their expectations. The 
test was carried out in the same way as the previous user tests in the project by first 

giving the user some information about how the test was to be carried out, before he/she was 
presented with the solution. What the user was informed about before the start of the test 

can be found in Appendix H. After the information had been given, the user was given access to 
the application and had tasks read out to him/her to carry out. All these questions in 

addition to the users' answers to questions that were asked after the completed test can be found 
in Appendix T. 


The test was conducted with three general testers and the domain expert. During the test, users 
were asked to perform various tasks in the system and register flocks of sheep they were shown 
on paper while walking a pre-defined "surveillance round" under observation. 

The figure below illustrates a flock of sheep the user was shown during the test. 


ÅT FEE 


> GR 


Figure 5.1: Illustration of a flock of sheep shown to the user during the final user test 


An element of the test that was difficult to simulate is the challenge of registering sheep at a long 
distance where the user observes them through binoculars and the sheep are in motion. 

This scenario therefore had to be carried out by telling the user that he/she could not observe 
anything else about the sheep other than how many there were and that they had a certain 
colour. 


The table below provides an overview of the challenges that were uncovered during the final user 
test of the system. EP1 stands for "Final user test problem 1" and EL1 stands for "Final user test 
solution". 
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Summary of End User Test Results, Mobile Application 


Suggested Solution 


Domain Expert EP1: Some problems with EL1: Found this out and thought even 
understand the use of the round afterwards that the buttons were logical 
buttons in the application -> no solution 

General user 1 EP2: Uncértainty about "load EL2: Add explanatory text to indicate that 
down map" button and whether downloading maps is necessary 
this is a necessary place in the start 
trip process 

General user 1 EP3: Problem figuring out which way the binoculars EL3: Change the direction of the swipe? 
mode button should be 
swiped to register sheep 


General User 1 EP4: Separate field for total number of sheep was EL4: Requested by domain user. 


confusing May need functional redesign and new 


rounds of user testing 
General User 1 EP5: Difficult to see which type of sheep is EL5: Use background color or similar to 
active visually in Binoculars mode highlight the active category 


General user 2 EP6: Uncertainty about cargo EL6: See EL2. 
down map functionality 


General user 2 EP7: Uncértainty about "Start EL7: Add a plus icon to indicate that you 


trip" button as it only showed å map are starting something new 


General User 3 EP8: Not immediately found EL8: Show a single number 
the completed trip for uploading to on the navigation bar to indicate that there is 
the cloud something waiting for the user in 
their profile 
General User 3 EP9: Geår was not intuitive to indicate old EL9: Explore other icon 
options 


Table 5.1: Summary of final test results for the mobile application 


Summary of End User Test Results, Web Application 


Suggested Solution 


General User 3 EP2: Thelflocks in the map could EL2: Make it clear in the map and side 


functioned as "voters" of flocks in menu which flock is selected and let the 


the solution user change this by clicking on flocks in the 


map 


Table 5.2: Summary of final test results for the web application 


The feedback from the user test was largely positive, and all users got through the tasks relatively easily without 
major problems. In addition, the system received a lot of positive feedback from the users in the interviews after the 
test. Several of the users stated that they thought the application was easy to use and that they thought the visual 
expression was 
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appealing. There was still some feedback on design choices or individual solutions in the 
applications that could be improved. These will not be improved through this project, but will be 
the subject of further development of the system. 


5.2 Comparison test 


In addition to carrying out user testing of the mobile and web application, tests of more traditional 
supervision tools were carried out to provide a basis for comparison for the developed system. 
The same questions and tasks were given to the users and they were asked to walk the same 
predefined tour. In this test round, however, the users were allowed to record their 

observations with pen and paper instead of the mobile application and NSG's 

proposed Excel sheet for generating a report instead of the Web application (NSG). 


Again, as in the previous test, it was difficult to simulate the challenge of registering sheep at 

a long distance with binoculars without the animals standing still. It was therefore again 
simulated by informing the user that he/she could see nothing but the number of animals and 
their colour. However, this does not give the overall experience of the difficulties of having to look 
down at the sheet and then find the herd with binoculars afterwards. 


The comparisons of the "manual" solutions and the developed system are based on the time it 
took the users to register flocks and events, the time it took the users to generate a report and 
the users' own feedback on the perceived differences between using the system and not. The 
table below presents the measured completion times for each task. 
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Time when using Time when using 
User Task å 
manual solutions the system 


Registration of a herd 02m 135 00m 3785 
Registration of an 01m 045 0Om 325 
event 
Generation of 03m 225 00m 075 
report 


Registration of a herd O1m 435 O1m 025 


User 1 


Registration of an 01m 365 00m 455 
event 
Generation of 02m 435 0Om 09s 
report 


Registration of a herd O1im 515 OOm 585 
Registration of an 02m 015 O1m 125 
event 
Generanon et 02m 065 0Om 135 
report 


Table 5.3: Overview of time spent on different tasks 


The times measured through the comparison test show that all registrations were completed 

faster when using the developed system compared to using manual solutions. Several users stated 
that they found writing by hand to be cumbersome and that afterwards they were not sure what they 
had written down themselves. One of the users also said that he could imagine that it would have 
gotten even worse if the herd had been on more animals (In this test they were only told to register 
6) and that he might not have been able to stand outside in bad weather and record details of the 
animals by hand. In addition, two of the users experienced that it rained during the test, which made 
using a notebook to record extra challenging. The figure below shows one of the users' notes after 

a surveillance round with the registration of three flocks and one incident and the same trip registered 
using the mobile application. 
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& Hans Karlsen 
4 3:14 


tegruppe * Oppdalsgruppa 


7 


Flokker 


Flokk 1 


Flokk 2 


Figure 5.2: Notes when registering sheep with Figure 5.3: Recorded trip using mobile 
pen and paper application 


Some of the feedback that was given after carrying out the same test with the mobile application 
was that it was more clear, faster to use and that the overview after the completed trip was 

much easier to deal with than when using pen and paper. It was also mentioned that when using å 
notebook, you did not have the opportunity to see where you had gone before or where you had 
gone when you had finished your walk, and that you could not record the position of the flocks 

of sheep. 


The comparison test of the web application was done with a focus on how quickly a user can 
generate a report based on the grazing season's observations. When using the manual 

solution, the user was asked to fill in the trip's registered details in an Excel sheet that NSG offers 
as a standard for digital organization of supervision trips (NSG). 

The Excel sheet has several pages where the user is asked to fill in information, but for this 

test the team let the users concentrate on the first three, as the fourth page focuses on calculations 
with a view to losses which the test users do not have the prerequisites to carry out without training. 
The users were given the chance to familiarize themselves with the Excel sheet in advance 

before the test started and the time was stopped when the trip was filled in and they were ready to print 
a report. When the web solution was evaluated, the user was told to do what was necessary 

to generate a report with the system. By looking at the execution times with each 

solution, it can be seen that the users saved an average of 2m and 34s by carrying out the 
generation of the report via the web solution. This is primarily because the web solution does not 
require any form of filling in, but is based on already registered data in the mobile 

application. 
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Rundt nabolag: Død Sau, Eier ukjent, mulig rovdyr 2 0:90 


beiteslipp i utmark 2. Tilsynslogg Tapsårsaker - kadaverfunn | 4. Oppsum. teg av dyr pram. arbedsnn 6. Sanlirg 


Figure 5.4: Excel sheet for manual generation of inspection report 


The feedback from the users when using Excel to generate a report when filling in details about 
the completed trip showed that several people found it cumbersome to use and that there was å 
lot of double registration of information. One user also mentioned that she doesn't 

thought the data was not orderly to read after the registration had been completed. In 
comparison, the web application received good feedback from all users that the solution was 
quick and easy to use and that the report that was generated was easy to read. 


115 


Machine Translated by Google 


6 Discussion 


6.1 Evaluation of the process 


For evaluation, the project process has been divided into four phases. The investigation phase, the design 
phase, the development phase and the test phase. 


The investigation phase 


The investigation phase consisted of working with domain knowledge and obtaining an overview of already 
existing solutions. This was done through conversations with domain experts 
and surveys via available online resources. 


The team found it challenging to get å good insight into how much existing solutions will actually cost a farmer and 
to do a cost analysis of the total price a farmer will have to pay to use the different options. Several of the 
solutions fall under schemes where farmers can receive grants from the state to subsidize purchases and 

use to increase animal welfare. The amount of these subsidies varies and there are several bodies that 

potentially subsidize the purchase of electronic tracking equipment (Findmy). 


Some of the solutions also offer price discounts for purchasing large quantities in addition to that 
the prices will vary over the years depending on whether you buy the bells or have them through a leasing 
agreement. 


It is also challenging to calculate how much å farmer will earn from his animals by slaughter each year, as this 
largely depends on the farmer's number of animals, how many losses he/she has had throughout the season 
and how fat the animals have become at the end of the season. 


Information was nevertheless found that could provide a basic overview of prices and size ratios. It was also 
established that there is no alternative on the market that meets the need this thesis explores and tries to come 
up with a solution for. 


Design phase 


During the design phase, several prototypes were prepared to evaluate the design and usability of the 

solution. The design was largely influenced by the users' feedback and carrying out several 

iterations of user testing and prototyping proved to have åa good effect as new challenges and opportunities for 
improvement were discovered at each iteration. They also found out about things that really worked well with the 
solution and good and thorough work through this phase saved the team from unwanted surprises during the 
development phase and during the final user test. 


Development phase 


Throughout the development phase, the team worked well and efficiently together and the use of Kanban as å 
development methodology helped the team to structure both time and tasks. The use of Github project 

boards to keep track of the tasks to be carried out proved to be very effective and the use of pull requests to 
ensure code quality worked well as several bugs were discovered along the way. The team has learned åa 
great deal through this process both in terms of code, architecture and collaboration. 
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The development period ended up being somewhat longer than the team had previously estimated 
as unexpected challenges arose along the way that took somewhat longer to resolve than had 
been estimated. In addition, both team members were dedicated to producing as complete å 
system as possible and the development time was extended somewhat on the basis of this. 


A technical challenge the team has had during development is instability in streaming updates to 
the map while a user is moving or the map is to be instantiated on the iPhone. The map will 

be loaded to the page, but there are occasional challenges with showing the user's position in 
the map. 


Another challenge the team has had has been stability in downloading maps, where the 
solution occasionally fails to load the map that is saved at the start of a trip. 

The mobile application will fall back on åa map solution that is retrieved via the web, so this only 
becomes å problem when you are outside mobile coverage. 


Test phase 


Several user tests were carried out throughout the project, both before and after the 

development phase. Carrying out the user tests turned out to be more time-consuming than the 
team had originally estimated. This meant that the development phase was shifted somewhat. 
However, the performance of the user tests was carried out in a satisfactory manner and produced 
a number of useful results for both documentation and further development of the system. In 
retrospect, it is considered that another user test of the solution should have been carried out 
halfway through the development period in order to get feedback on the developed product 

along the way. 


The test plans that were drawn up for the user tests ensured that all users received the same 
information and had the same prerequisites when carrying out the tests. 

It also proved effective to design roles for the team members during the execution of the 
tests so that as few details as possible were missed. 


6.2 Evaluation of the solution 


In order to evaluate the developed system, the final user test of the system and the 

comparison test that was carried out at the end of the development period will be used as åa 
starting point. Based on the data obtained through these user tests, the system will be evaluated 
in relation to the designed research questions in the section "Aims and problem". 


Research question 1: 


How much more efficient is it to record observations using Beitemaster as opposed to current 
methods? 


The Beitemaster system was developed as an alternative to manual methods for registering sheep 
on open pasture. The main aim was to streamline the execution of inspection trips 

and the generation of reports for applications for compensation for lost grazing animals. 

Through the final user test documented in the section 

"Results", it was found that when registering a selected event, the test subjects saved 

an average of 44 seconds. When registering a selected herd, the test subjects saved an average 
of 1 minute and 3 seconds. These findings were somewhat surprising to the team as 

their personal hypothesis was that as note taking is 
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something known to everyone, this would be faster than using the app for the first time. 
This was because the testers would not be familiar with the system's user interface before. 
However, this was not the case, which was a positive surprise in the system's favour. 

It is likely that the difference in time will also increase as users become more familiar with 
the system's user interface. 


While 44 seconds faster for each event and 1 minute and 3 seconds faster per herd may not 
sound like much, this will add up to significant time on a ride with many herds and events. In 
addition to the specific time measurements of the various registration processes, several of the 
users referred to the manual solution as cumbersome 

and time-consuming to use. 


Based on these findings, the team concludes that the system that has been developed is more 
effective for recording observations than current methods. Concretely, it saves 
users approx. 1 minute per registration during an inspection tour. 


Research question 2: 


How precise, detailed and sufficient is the information recorded using Beitemaster compared to 
current methods? 


Through the final user test, the completeness of the data recorded during an inspection visit using 
the mobile application was evaluated. One of the tasks given to the test subjects was to access 

the completed trip uploaded to the cloud through the web application and evaluate that the 
recorded data corresponded with what they recorded in the app. All test subjects found that the 
data they had recorded in the app during the inspection tour matched the data displayed in the web 
application. 


Through the interviews conducted after the final user test, feedback was given from 

several of the test users that the information they found on the page for completed 

trips felt complete, complementary and sufficient. This was also mentioned by the domain user 
several times during the execution of the test. In addition to this, it was expressed by one test user 
that he would hardly have been able to record as many details with paper and pencil as he could 
with the application, because it would have taken too long and been too much work. 


Based on the findings made through testing, conversations and interviews with the 
test subjects, the team finds that the data registered via the app is very precise, more detailed than 
when registering with pen and paper and more than sufficient for domain users. 


Research question 3: 


How much more efficient is it to produce reports using Beitemaster as opposed to 
traditional methods? 


When carrying out the comparison test, it was measured how much faster it was for users to 
generate a report using the system, compared to the digital alternative NSG offers via åa 
standardized Excel sheet. In order to produce a report after a completed inspection trip witn NSG's 
solution, users had to fill in data about the trip in the sheet, where the total number of sheep, 
incidents and so on were calculated. 

During the test, the users were only asked to fill in 3/6 pages in the Excel sheet, as several of the 
last pages consist of more complex filling patterns. Several users expressed during the test 

that it felt cumbersome to have to record the data they had written down on paper again in the 
sheet and several felt that it was demanding to understand how the information should 
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is filled out. With the help of Beiteweb, users could generate reports directly, based on the information that 
was already registered in the solution when using the mobile application. 


When using Beiteweb to generate a report, users saved an average of 2 minutes and 34 seconds. It is also 
important to note here that during the test the users were only asked to register three flocks and one incident 
from the inspection tour carried out. 

This is an unrealistically low number for a real inspection tour. Throughout the season, the time it takes to register 
this data after each trip will be significantly more time-consuming as there will be more trips, more flocks and 
more events to register, in addition to the fact that you should fill in the complete form. 


If one assumes that it takes the user at least as long to register a trip as it took the test persons on 
average in the final user test, and the sheep are grazing for approx. 

20 weeks each season, it can be estimated that the user will save at least 51m 205 per season 
when registering with Beitemaster, but the figure is probably significantly higher. 


Research question 4: 


How well does Beitemaster meet the users' needs when it comes to monitoring sheep on open pasture? 


Through all the tests carried out through this project, the users' needs have been in focus. Each user test has 
helped to reveal potential for improving the solution and how the users' needs could be better met. At the 

end of each test, the users have also been given the opportunity to comment on elements they have missed or 
could have imagined in the solution. When the final user test was carried out, the feedback was exclusively Ul- 
focused and all users thought the data basis and the user-friendliness of the system were very good. The 

domain expert stated that the system was one of the best he had seen of its kind and that it met all his needs on å 
supervisory tour, in addition to offering functionality he had not thought of himself. 


The performed system test described in "System testing" validated that the system fully meets all but 2 of 
the functional and non-functional requirements, and these 2 
was partially fulfilled. 


Based on feedback from users throughout the project and at the end of the project, the domain expert's 
assessments, in addition to the evaluation of the system through the system test, the team considers 
that the system meets the users' needs very well. 


6.3 Goal achievement 


Performance target 


Early in the project phase, results and impact targets for the system were drawn up. 

The result targets consisted of achieving defined functionality for mobile and web applications, 

make the system available to all users in the target group and ensure that the system complies with the 
current requirements of the GDPR. 


The mobile application and the Web application's final functionality are presented and discussed in the 

"Product" section of the report. All the defined requirements for both applications have been 

implemented and carried out according to the prepared requirements specifications. 

Through the system test which is presented in the section "System testing" and which can be found in its entirety 
in appendix S, the requirements and performance targets were related to system functionality 
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evaluated. The findings through this test showed that all the requirements and goals in this 


area have been met with the exception of 2 points related to the preservation of data when a user is 
deleted. 


In the section on "Technology choice" and the discussion on choosing Flutter as åa development tool 
the choice of Flutter is justified by the fact that it supports both the Android and iOS platforms, which 
over 99% of mobile users in Norway and 98% worldwide use. In addition, Flutter meets the technical 
requirements set for the system by supporting operating systems for both phones running 

Android 9 or later and iOS 12 or later. Based on this, the team considers the target group for the 
product to have been reached. Nevertheless, there will always be individuals who will not be reached 
by the solution, such as people who do not use telephones or who run operating systems so 

old that Apple and Google no longer support them. 


GDPR has been a focus throughout the development of the system and, as discussed in the section 
on "GDPR and privacy", the team has followed current guidelines and prepared the system for 
compliance with the Norwegian Privacy Act. 


Performance measures 


The impact targets included simplifying and streamlining the registration of observations, completed 
inspection visits and the generation of reports for submission to the Norwegian Environment 
Agency. In addition, the system should help make it easier to keep track of the grazing team's 
common data and its own sheep and loss figures. 


Through the evaluation of the solution made in the section above, where the research questions 
was answered, it was discussed that the final user test and the comparison test showed that it is 
easier and faster for users to record observations during a supervision visit than before. It is 

also easier to register completed trips and easier and more efficient to generate a report than with 
the traditional methods. 


The last effect target has been difficult to measure during the project period and must be 

evaluated by supervisors who take the solution into use over time. But based on the domain 

expert's experiences of how information is shared between farmers today, 

either by means of shared documents or by explicit communication around the topic, it is reasonable to 
believe that the system fulfills the goal of simplifying the process of keeping track of its own and 
shared data. 
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7 Conclusion and further work 


7.1 Conclusion 

The main aim of this project was to develop å system that could help supervisors and 

farmers by simplifying their everyday life during the grazing season and streamlining the processes 
around supervision trips and documentation. 


In order to be able to achieve this goal, the team has had to become familiar with the domain and 
logistics surrounding the operation and keeping of livestock on open field pastures in Norway 
throughout the project period. Based on research in the area and collaboration with domain expert and 
supervisor Professor Hvasshovd, requirements specifications and project goals for the system 

were drawn up. Four research questions were set which dealt with how much the 

system could improve supervisors' experience and time spent on supervision trips and when 
generating documentation for the grazing season. 


The prepared requirements specifications and performance targets laid the foundation for modeling 
user stories, application flows and å conceptual model that became critical for the system's design. 
The design was then revised in several rounds following feedback from users through user tests, 
before the development period began. 


Based on the work to date, the system architecture was drawn up, and the modeling of the database 
was carried out. The choice of technologies was largely influenced by the defined target 

group, the requirement specifications and user feedback on the desired functionality. Several 
alternatives to technologies were evaluated before the final choices were made. During the 
development period, a Web application and å Mobile application were developed with 

a common backend service with a common database. The team got to work with several 


development languages and technologies, and had a focus on test writing and security along the 
way. 


At the end of the development period, final user tests were carried out and a comparison test 

of how the system measured up in terms of time compared to the currently available solutions. Based 
on these tests, the research questions were answered and the goal achievement of the system 

was evaluated. 


When answering the research questions, it was shown that; 


- The system is more efficient when recording observations on inspection trips than with 
traditional methods and that it saves users approx. 1 minute per registration during an 
inspection tour. 

- The system is very precise, more detailed than when registering with pen and paper 
and more than sufficient for domain users. 

- The system is more efficient for generating reports than when using 
traditional methods and Beiteweb saved users an average of 2 minutes and 34 seconds 
when generating a report. This number is likely to be higher for a real inspection tour. 


- The system meets the users' needs very well. 


When evaluating the system's target achievement, it was shown that all the system's performance 
targets were met in a satisfactory manner. The system's performance targets were also largely met 
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apart from the goal of simplifying the process of keeping track of their own and shared data. 
This target proved difficult to measure during the project process and must be measured over time 
when using the application in real pastures. 


The team has worked independently and independently of other entities and has thus largely 

made its own decisions and decisions about the project. The final system is an overall functioning 
system with a well-worked design expression that fulfills the requirements and goals that were set at 
the start of the project. It has been shown that the system is more effective than traditional 

methods and it has received good feedback from both test subjects and domain experts. 

This suggests that the development has resulted in å good product that users find useful. 


7.2 Further work 


Although the final system meets the objectives and the users' expectations, there are several 
areas that can be improved and developed further. 


Testing in real scenarios 


The solution was never tested in a completely real scenario in real pastures as the task took place 
out of season and the domain expert did not have access to domain testers. This is something that 
should be implemented in order to get more feedback on the system in relation to the users who 
will actually use the solution. This will also make it possible to evaluate the system's latest 
performance measures, which were largely not evaluated during the project period. 


Administrative functionality in the web application 


As of today, there is no functionality to update the profile picture, edit groups or accept invitations 
to grazing groups in the web application. This is functionality that would have been natural to 
implement and which could improve the users' experience of the web application. Due to the 
time aspect for the project, this was not carried out, 

but marked as further potential for the application. 


Improvement of results from final user test 


Potential for the improvement of some Ul elements was revealed through the final user test, which 
may be appropriate to explore further and improve based on the users' feedback. Some of this 
feedback included visual elements that were difficult to capture through sheep registration and 
which way the user had to swipe to register sheep in binoculars mode. 


Options for generating reports in the web application 


Another area that could be interesting to explore is giving the user the opportunity to choose 
which data fields are interesting when generating reports. This could have been done by giving the 
user access to fill in a more detailed form before generating a report where they could 

decide for themselves which data from the grazing season the report should contain. In this way, 
the user will have more control over the design of the report and the report can be useful in even 
more scenarios than as of today. 
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Resolving GPS and offline map stability issues 


As the team is aware of instabilities in loading the user's position in the map on the iPhone and 
instabilities in accessing offline maps when used outside coverage areas, these are areas that 
should be worked on in order to achieve a better solution. 
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A. Gantt chart 
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B. Requirements specification 


Prepared 07/09/2021 


Technical requirements 


* Must run on both Android and iOS 

* Must support android > Queen Cake 10 https://endoflife.date/android * Must support iOS 

>= 12.4.x https://support.apple.com/en-us/HT201222 

* Must have sweet tea for gps 

* Must be able to process and display map data offline (Desired map data from the mapping authority) 
* Must be able to handle Text-to-speech/voice messages 

* Must be able to handle logging without internet access * Must be able 

to upload log data to the cloud via wifi 


Application requirements 


* Support creation of user and login 

* Support the creation of grazing groups with members and farms 

* Support presentation of grazing groups with associated information and previous trips 

* Support logging of inspection trips with all relevant information 

* Support downloading maps of the relevant grazing area before a trip begins 

* Support registration of the number of lambs and sheep including color seen during inspection trips 

* Support the possibility of registering detailed information about the sheep such as the sheep's farm 
affiliation, the number of lambs there should be in the flock based on ties and identifying whether there is the 
correct number of lambs in the flock. 

* Support the possibility of registering sheep without having to look at the phone when observing 
sheep more than 30 meters away. 

* Support possibility to place an observed herd in the map during registration. 

* Support for recording where the supervisor has gone through the round. 

* Support uploading of photos from the trip (sheep/flock, dead sheep, remains, etc. - also injured 
sheep) 

* Support registration of time and date (essential in all logging, e.g. when you see the sheep, start a trip, 
times a flock of sheep is observed during a trip) 

* Support the generation of a log for the inspection round and display relevant information 

* Support storing logs and documentation in the cloud 

* Support display of grazing quality in maps of the grazing areas 

* Support the generation of reports in åa standard format based on the grazing season 
events 
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C. Application flow Mobile application 
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D.Application flow Web application 
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E. Conceptual Model 


Concepts 


Each concept element in the application represents an entity that is used in relation to other entities to together 
form a system. The role of the conceptual model is to put the entities in a system so that you can more easily see 
the connections in the system and can simplify the relationships between them. Based on this, it will hopefully 

be easier for the end user to map the system and the relationships when they use the system. Each entity has åa 
number of attributes that together make up the entity. 


User 


User refers to a user in the system. Å user contains data about the system user such as name and which groups 
they belong to. 


Attributes: 


- Email 

- First name 

- Surname 

- Pictures 

- Admin status 


- Group affiliations 
- Completed trips 


Operations: 
- Change or delete the profile 


- Change administrator status 
- Create grazing groups 


Grazing group 

Grazing groups are named groupings of users who work together to carry out inspection trips. Administrators can 
create farms, invite users and edit data. 

All users can register trips in the group and evaluate the recorded data. 


Attributes: 


- Name 
- Members 
- Tours 
- Farms 


Operations: 


- Change or delete information 
- Add members 

- Add farms 

- Register trips 

- Evaluate data 
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Farm 


Farm represents a farm involved in the grazing group. Sheep and lambs that are registered 
belong to a farm and can be identified by the color of the patch in the ear that corresponds to the 
color of the farm in the group. 


Attributes: 


- Name 
- Color 


Operations: 


- Change color 
- Change name 


Trip 

Trip represents å supervisory trip å Supervisor undertakes for a grazing group. Throughout the trip, 
information about herds and observed events is recorded. Positions the user has been in are also 
recorded. 


Attributes: 


- Flocks 
- Events 
- Distance 


- Positions 
Operations: 


- Register herds 
- Delete herds 


- Register events 
- Delete events 


Event 


Incidents are observations or events that occur while a user is carrying out an inspection 
tour. The user registers the event with a title, category and description of what has happened. Photos 
of what has occurred can also be added. 


Attributes: 


- Title 


- Category 
- Description 


- Position 
- Pictures 


Operations: 


- Register data about the event 
- Add/remove images 


Herd 


Herd is an observed group of animals during the execution of a trip. When the user 
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If you observe a herd, it is registered on the trip being carried out. A trip may contain many sheep 
and lambs in addition to notes about the flock and photos that may be relevant for documentation. 


Attributes: 


- Sheep 
- Lamb 
- Note 


- Positions 
- Pictures 


Operations: 
- Register sheep 
- Delete sheep 


- Register lambs 
- Delete lamb 


- Add/remove images 


Lamb 


A lamb has information about the color of its wool, which farm it belongs to according to the color of 
its ear tag and whether it is damaged. You also have the option to write a note on the lamb for 
further information. 


Attributes: 


- Color 


- Brand color 
- Condition 
- Note 


Operations: 


- Register/Change data 


Sheep 


A sheep has information about the color of its wool, which farm it belongs to according to the 
color of its ear tag and whether it is damaged. The color of the tie indicates how many lambs 
the sheep should have with them during the grazing season. You also have the option to 
write a note on the lamb for further information. 


Attributes: 


- Color 
- Brand color 


- Tie colour 
- Condition 
- Note 


Operations: 


- Register/Change data 
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Design metaphors 


The design metaphor for the mobile application chosen is a notebook. The notebook is the traditional way 
of recording data about an inspection visit. The farmers will traditionally take a notebook with them on 
their trip and write down data they observe along the way. As the main purpose of the mobile 

application is to record such information, the notebook has been chosen as a metaphor. 


The design metaphor for the web application is a ring binder or an Excel sheet. Traditionally, farmers 
would copy over data recorded when they returned from a trip either to paper or to an Excel sheet to save 
it until they needed to evaluate data or submit documentation to the authorities. As the web 

application's purpose is to structure data for evaluation and generating reports, this is the design 
metaphor chosen. 


Concept translation 


This section contains an overview of which real-life entities each conceptual entity can be 
translated into. 


Conceptual entity Real entity 


User 
Grazing group 
Farm A farm with sheep on open pasture 


Even 
Fe 
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Relational Model 


Email 
First name 
Last name 
Picture 
Admin status 


Group affiliations 
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Performed trips 
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F. Persona 1 Hanne Hove 
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G.Persona 2 Odd Larsen 
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H. Test introduction for user tests 


1. Introductions by the test administrator and note taker 

2. Describe the observations made during the test for the subject 

3. Inform the subject that no help will be given during the test and that they are encouraged to 
find their own solutions 

4. Inform the test subject that it is okay if you cannot find the answer to one 
task or make mistakes along the way, it is also ok to end the test if you wish 


5. Inform the subject that the prototype is a lo-fi prototype and that it is not 
can be expected to be perfect or polished, it is permissible to inform about things that 
appear confusing 

6. Ask the test subject to think out loud during the test and let the administrator know what 
which lies behind the decisions that are made. 

7. Introduce the application and the purpose it is intended to solve 

8. Ask if the subject has any questions 

9. Give the tasks to the subject 
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I. Tasks and questions, Paper prototype 


The tasks below must be solved during testing of the paper prototype: 


1. You are a farmer who has just gained access to this system. You are a member of a grazing team 


that includes two farms and 4 supervisors. Create a group for the grazing team and add one of the 
farms and one of the supervisors. 


2. You are going out on å supervision round for the grazing team. Start a new inspection trip 
for the grazing team called Oppdalsgruppa. 

3. Out on the inspection tour, you observe a flock of sheep. The sheep are quite far away and you have 
to use binoculars to see them. Register this flock while using binoculars to see them. (Instructed to 
register without looking at the phone and is read out 1 brown sheep and 3 brown lambs) 


4. Still out on the inspection tour, you observe a new herd quite close to you. Register a new flock of 2 
gray sheep with red markings, where one of them has a green tie and the other has a yellow tie. In 
addition, you see 3 gray lambs with red markings. 


5. On the trip you observe åa dead animal. Record this finding and then exit 
the trip. 


Questions asked after the user test: 


Domain Expert: 


1. What did you think about the flow of the application? 

"I thought the flow made sense, but it doesn't make sense to have Farms as a separate element 
that you can access and I was confused by what you would find if you accessed this menu. In 
addition, the binoculars registration was far too detailed. You will never be able to go back and 
record more details as the herd moves and you tend to lose the sheep you are looking at along the 
way.” 

2. Were there any buttons you werent sure what they did? 
"No, the only thing I thought about was that there were plus buttons both on the grazing 


group side and on the front, which can make it somewhat unclear what each plus refers to, 
but I still think it was fine." 


Test subject 1: 


1. What did you think about the flow of the application? 


"I think the flow worked well, the only thing I was unsure about was what Gårder was." 


2. Were there any buttons you werent sure what they did? 
"No" 


Test subject 2: 


1. What did you think about the flow of the application? 
"I found it very messy and difficult to use the binoculars registration. 
It was very long and there were many details available that were not relevant to record.” 


2. Were there any buttons you weren't sure what they did? 


"No, I thought the buttons made sense and I figured out what to do although paper is a bit hard to 
make out as everything is flat." 
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J. Questions and 
answers, Figma prototype 1 Mobile application 


The tasks below must be solved during the first testing of the Figma prototype: 


6. You are a farmer who has just gained access to this system. You are a member of åa grazing team 
that includes three farms and 5 supervisors. Create a group for the grazing team and add one of 
the farms and one of the supervisors. 

7. You are going out on å supervision round for the grazing team. Start a new inspection trip 
for the grazing team called Oppdalsgruppa. 

8. Out on the inspection tour, you observe a flock of sheep. The sheep are quite far away and you have 
to use binoculars to see them. Register this flock while using binoculars to see them. (Instructed to 
register without looking at the phone and is read out 1 brown sheep and 3 brown lambs) 


9. Still out on the inspection tour, you observe å new herd quite close to you. Register a new flock of 2 
gray sheep with red markings, where one of them has a green tie and the other has a yellow tie. In 
addition, you see 3 gray lambs with red markings. 


10. On the trip you observe å dead animal. Record this finding and then exit 
the trip. 


Questions asked after the user test: 
Domain Expert: 


3. What did you think about the flow of the application? 
"The flow works well, it was easy to navigate around and I found the different options 
took me where I expected to land." 
4. Were there any buttons you weren't sure what they did? 
*No, I found the icons and text to be intuitive. However, the large button on the scope 
registration page was not that intuitive to use as I thought it should be swiped and not clicked.” 


5. Did binocular mode have the right amount of detail? 
"I thought the level of detail was good now. I did not immediately understand where I could exit the 
registration once I had registered the number of sheep." 


Test subject 1: 


3. What did you think about the flow of the application? 
"Thought it was good. Had no problems finding it.” 

4. Were there any buttons you weren't sure what they did? 
"Was a bit unsure of what the button to switch between binoculars and manual mode was, but 
found out by testing it." 

5. What did you think of the sheep registration flow? 
"I thought it was logical, but I didn't like having to write in the fields to record the number of sheep. It 
was easier to use binoculars mode in this prototype, but it didn't make sense to have to click the big 
button instead of being able to swipe left and right.” 


Test subject 2: 


3. What did you think about the flow of the application? 
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"I found it to be improved and easy to use. It was a little difficult to understand how to switch 
between binocular mode and manual mode, but after I understood what the button did, it 
worked fine." 

4. Were there any buttons you weren't sure what they did? 
"Yes, to be honest, it was a bit difficult to understand how to switch between binocular mode 
and manual registration. But I thought it went well after I tested it.” 


5. What did you think of the sheep registration flow? 
"I thought it was good. I got what I wanted recorded.” 


Test subject 3: 


1. What did you think about the flow of the application? 
"The flow was good, nothing to complain about." 
2. Were there any buttons you werent sure what they did? 
"No, thought it was fine." 
3. What did you think of the sheep registration flow? 
"I thought it was good, didn't like having to enter the number of sheep. Thought it was unnecessary 
when there were only one or two.” 
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K. Questions and 
answers, Figma prototype 2 Mobile application 


The tasks below must be solved during the second testing of the Figma prototype: 


11. You are a farmer who has just gained access to this system. You are a member of a grazing 
team that includes three farms and 5 supervisors. Create a group for the grazing team and 
add one of the farms with blue color and one of the supervisors. 

12. You are going out on å supervision round for the grazing team. Start a new inspection tour for 
the grazing team named Drangedalsgruppa. 

13. You see a herd and place it on the map. (awaiting implementation) 

The flock of sheep moved as you looked at the map. Record the position of the herd. 

14. Out on the inspection trip you observe a flock of sheep. The sheep are quite far away and you 
have to use binoculars to see them. Register this flock while using binoculars to see them. 
(Instructed to register without looking at the phone and is read out 2 black sheep and 2 black 
lambs) 

15. Still out on the inspection tour, you observe a new herd quite close to you. Register a new flock 
of 3 brown sheep with blue marks, where one of them has å yellow tie and the other has a red 
tie. In addition, you see 1 gray lamb with a blue mark. Add a picture of the herd. 


16. After this you see another herd, but this one is far away. You don't see the color 
the sheep, but you see there are 5 of them. Register this herd. 
17. On the trip you observe a predator. Record this find and add å photo and then end the tour. 


Questions asked after the user test: 
Domain Expert: 


6. What was your experience with the application? 
"It feels g00d, I think it flows well and that the structure is logical, but it seems that there is no 
way to get out of registering a herd on the map if you have clicked to place it. In addition, it 
may not make sense to leave grazing area as a separate concept. Each supervisor should 
perhaps be allowed to choose their own map section to follow.” 


7. Was there something you felt you were missing or looking for along the way? 
"No, I think most of it is covered." 

8. What did you think of the sheep registration flow? 
"I think that the buttons you press to increase or decrease the number of sheep you 
register are a little small, and they could well be a little bigger to make it easier to hit them 
when you're out for åa walk or moving around." 


Test subject 1: 


1. What was your experience with the application? 
"Perceived well, but a bit unsure of what grazing area really is." 
2. Was there something you felt you were missing or looking for along the way? 
"Perhaps the map on the start trip screen could have been a little bigger since it now does 


not fill the screen. It would also perhaps be nice to be able to add a comment on å sheep and not 


just on the flock." 
3. What did you think of the sheep registration flow? 
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"I think it was better with buttons, it felt better to click than to type in numbers." 


Test subject 2: 


1. What was your experience with the application? 
"I think it looked good." 
2. Was there something you felt you were missing or looking for along the way? 
"I was thinking that I couldn't see which group I went for under the information 
in the menu on a trip. I also thought that if there is an injured sheep I might want to 
record it directly in the flock or on a sheep.” 
3. What did you think of the sheep registration flow? 
"I think it worked well." 


Test subject 3: 


1. What was your experience with the application? 
"Good, but didn't get out of the registration module when I tried to move a flock's position 
on the map." 

2. Was there something you felt you were missing or looking for along the way? 
"No not really. » 

3. What did you think of the sheep registration flow? 
"I liked the buttons to add sheep better than typing in numbers. Otherwise, it was good 
and it was fun to be able to add photos." 
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Mobile Application 


L. Paper Prototype 


Home screen 


Grazing groups screen Start trip screen 


Screen during trip with map Binocular mode for The registration process in 
for registering flocks and flock registration binocular mode 
menu for registering events 


Manual mode for 


registration of herd 
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M.Figma prototype Mobile application 


Aktivitetslogg 


Ø Dalføret 
Kart 12.09.21 
Rød Gård - Per Stålesen 


Tregrensa 
09.08.21 
Gul Gård - Jan Johansen 


Dalføret 
05.08.21 
Blå Gård - Truls Nilsen 


Dalføret 
09.07.21 
Rød Gård - Svein Petter Olsen 


Tregrensa 
06.07.21 


Brun Gård - Rita Rønning + 


V 


Beitegrupper Profile 


Home screen with recent 
activities 


Siste aktivitet 


Ø bolføret 
Kart 12.09.21 
Rød Gård - Per Stålesen 


Ø Dalføret 
Kart 12.09.21 
Rød Gård - Per Stålesen 


Ø palteret 
Kart 12.09.21 
Rød Gård - Per Stålesen 


Statistikk 
Døde sau: 5 Turer gjennomført: 
Skadde sau: 10 Sauer sett: 
Medlemmer 
Per Stålesen Rød Gård Admin 
Kristian Aasen Grønn Gård Bruker 


Kari Johansen Blå Gård Bruker 


Gårder 


Overview of the contents of åa 


grazing group 


Beitegrupper 


Dalføret 
3 gårder, 9 oppsynspersoner 


Tregrensa 
2 gårder, 4 oppsynspersoner 


Beitegrupper Profile 


Grazing groups screen with the 


user's groups 


Beitegruppe Dalføret 
Beiteområde Vestre område 


Last ned kart over beiteområde — 0bs, kart er ikke 
nedlastet 


The home screen for an 
inspection tour 


Profil 


Petter Hansen 


Rød gård, Gul gård, Blå gård 


Mine instillinger 


Mine turer 


Mine kart 


Mine invitasjoner 
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The screen for a started trip 
with map and button for 
registering flocks 
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Vis historisk data Vestre område 17.08.21 


Tid brukt: 2t 44m 235 
Distanse: 11km 


07.08.21 Per Stålesen 


01.08.21 Truls Nilsen 


Legg til kommentar/notat 
20.07.21 Svein Petter Olsen 


? Legg til hendelse 


13.07.21 Trine Helgesen 


01.07.21 Per Stålesen 
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The screen for registering 
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End of 
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Avbryt registrering 


Antall dyr 


Avbryt registrering 


Slips Rød 


4 SAU -BRUN 


Tag Blå Slips Blå 


5 SAU -SORT 


Tag Grønn Slips Blå 


OBS! Det mangler 1 lam i denne flokken etter registrerte 
opplysninger. Etterse at antall lam og fargen på slips 
stemmer. 


Øl Legg til bilde 


Legg til kommentar 


Overview of manual registration 


of a herd 


Registrer mer info 


Øl Legg til bilde 


Legg til kommentar 


Manual registration after redesign of 


the input fields. 
Shown here without any sheep 


registered 
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RA 


Antall lam 


4 


Kjokkeslett 


10:03 


Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed 
do elusmod tempor incididunt ut labore et dolore magne 
aliqua. Vi enim ad minim veniam, quis nostrud exercitation 
ullameo laboris nisi ut aliquip ex eå commedo consequat 


Duis aute ure dolor in reprehenderit in voluptate veit esse 


eillum dokore eu fugiat nulla pariatur. Excepteur sint occaecat 
cupidatat non proident, sunt in cuipa qui officis deserunt. 
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Overview of a completed 
trip 
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N.Figma navigation structure, 
Mobile application 
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O. Figma prototype Web application 


Dashbord 
Sesong 2022 


ta 


Ted Hansen 
Døde sauer 


d 2 


En) Årets turer 


Dato 


04.01.2022 
20.01.2022 
02.02.2022 
05.02.2022 
24.02.2022 
17.03.2022 


01.04.2022 


Q 


Profil 


The front page of the web application when the user is logged in. Displays information about a selected 


GrazingGroup 1 
Ted Hansen - 04.01.2022 


Distanse 
23.34 km 


Flokk 1 
Antall sau Antall lam 
7 å 
Skader Klokkeslett 
1 10:03 
Kommen 
kfem ipsum dolor sit amet, consectetur 
elit, sed do eusmod incididunt ut labore et 
magna aliqua. Ut enim ad minim 
quis nostrud exercitation ullameo laboris risi ut 
akquip ex ea commodo 


Turer gått Rovdyr sett 
2 2 2 

Oppsynsperson Sauer sett Hendelser 
Ted Hansen 14 va 

Kim Tronsen 18 va 

Åge Normann 23 vw 

Tore Fransen 32 ”A 

Kim Tronsen 4 vW 

Ken Yee 23 åa 

Åge Normann 16 


grazing group. 
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Sau 1 +88 Lam 1 
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Sau 1 +08 Lam 1 
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Sau 2 En] Lam 1 


» Grå + Røed Gård — + Grønt slips 


The overview of a trip with details. 
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FA 
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lam - kl 10:03 
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Flokk 4 
+ å lam «kl 10:03 
5 
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lam - kl 10:03 


Hendelser 
Hendelse tittel 1 
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Rapport 
Ted Hansen Beitegruppe: Beitegruppe v 
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Page for selecting report data 
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Ted Hansen 
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Rapporter 
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Oppsynspersoner 


Tid brukt på oppsyn 
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Oppsummering 
Sauer observert 


Funn av døde dyr: 


Observasjoner av rovdyr 5 


Tur 1 Avvik/Merknad 
26/05/2022 


Odd Larsen 


Flokk 1 Sett kl Sau Lam Posisjon 


Q 


Profil 


Generated report 
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P. Questions and answers, Figma prototype 
Web application 


The tasks below must be solved during testing of the Figma prototype of the Web application: 


18. You are a farmer who has just gained access to this system. You have been invited to åa 
grazing group and have accepted the invitation. Find out how many trips have been taken in 
the Oppdal group so far this season. 

19. You have carried out an inspection and want to see that the information you have 
registered is correct. Access the last trip you completed and check that the number of herds 
registered is 3. 

20. During the trip that was carried out, an incident was recorded. Inspect the photo taken 
during this event and find out what happened. 

21. Generate a report on the grazing season so far. 


Questions asked after the user test: 
Domain Expert: 


9. What was your experience with the application? 
"It was very good, I thought it was logical to navigate through. Easy to find what you wanted 
to watch.” 
10.Was there anything you felt you missed in terms of information? 
"| missed åa line between the registration point on the map and the herd you 
registered. In addition, it would have been very nice to be able to see pasture quality in the map. 
It is very useful for farmers to know about.” 
11. What did you think of the overview of a completed trip? 
"Thought it was clear and nice. You get all the information you need there." 


Test subject 1: 


1. What was your experience with the application? 
"Overall good flow. Perhaps you could have å dropdown to select seasons, also like with 
grazing groups instead of bringing up all trips on a form if you click on previous seasons?" 


2. Was there any information you felt you missed? 
"I thought it was good information, but I think maybe it could have been an overview of what 
the different things marked on the map mean." 

3. What did you think of the overview of a completed trip? 
"Thought it was neat and clear." 


Test subject 2: 


1. What was your experience with the application? 
"I liked the side menu and that everything was accessible from there." 


2. Was there any information you felt you missed? 
"I think it could have been explained what the different icons in the map are. Sheep are fine, 
but it would be nice to be able to click on them and see info about them too." 


3. What did you think of the overview of a completed trip? 
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"Thought it was nice and clear." 
Test subject 3: 


1. What was your experience with the application? 
"Thought it worked well, it was very easy to produce a report so that was very good. Perhaps a bit 
difficult to distinguish between what were buttons and what were not.” 
2. Was there any information you felt you missed? 
"No, I think everything looked good." 
3. What did you think of the overview of a completed trip? 
"Thought it was good, maybe could have had slightly bigger headlines." 
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Q. Figma navigation structure, 


Web application 
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R. Success criteria analysis 


Success omena auae of WCAG 2.0 


| ÆN umber ET Degree of fulfillment 


Non-textual 
content 


Audio only and 
video only 


Meaningful 
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Sensory All data in the mobile and web app is 
properties explained with text or in 
combination with icons and colour. 
The only area where this deviates are 


the areas mentioned in point 
LA 

Use of color No information in the app is only indicated 
or communicated using color. All color 
coding is supplementary to textual 
or other visual descriptions. 


Control of sound The user has the option to turn down 
the sound on voice messages that are 
read out in the mobile application by using 
the mobile's built-in functionality. 
The user also has the option of registering 
sheep in manual mode so as not to hear 
voice messages. 


SJ 


1.4.4 Changing Parts of the mobile application cannot be 
text size enlarged up to 200% size. This is 
something that needs to be improved. 


Images of text There are no images of text in the mobile 
TJ MP Pl 
12 2.1.1 A Keyboard All functionality in the 
web application is accessible via 


No keyboard trap There åre no keyboard traps in 
the web application 


Adjustable There are no time 
speed limits in the mobile or web application 


Pause, stop hide There ig no content in the mobile or web application 
that changes automatically. 


Threshold value on There is nothing in the mobile or web app 
a maximum of three that flashes 


17 2.4.1 A Jump over Users cannot currently jump to the main 
blocks content when tabbing. 


18 2.4.2 A Page titles All pages in both the web and 
the mobile application have clear page 
titles that describe the content 
on the side. 

19 2.4.3 A Focus order The content on the website is 
presented to the user in a logical order. 
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webapp, the content is sorted by utility 
and most recently registered info. 


either in the web or the mobile 
application. 

Multiple ways As of today, the menu in the 

to navigate web application is the only way to 
navigate the application. This is 
something that needs to be improved 
with, for example, a site map. 

Headings and All prompts and headings in both the 

prompts mobile and web application are 
descriptive and describe 


functionality or information found 
under 


23 2.4.7 AA Visible focus All content on the web page gets visible 
focus when å user navigates with 
a keyboard 
specified in index html. 


25 3.1.2 AA Language on parts of No parts of the web or mobile 
the page application are in languages other 
than Norwegian 
26 3.2.1 A Focus No elements that receive focus in the 
mobile or web application cause 
significant changes to the page 
Input data No changes to values in form 
fields lead to major changes in 
the user interface either on mobile or 
the web application 


Consistent In the mobile application, 
navigation the navigation menu will always 
remain in the same order 
and the back arrows in the top menu 
will always appear in the same 
place. In the web 
application, the navigation menu 
will always have the same order. No 
other navigation elements are 
repeated across multiple pages. 
Gonsistent All buttons in the mobile and 
identification web application have the same 
expression to meet the 
users' expectations. 
Identification of Where forms display error messages, 


errors the error message is displayed 
below the relevant field so that the user 
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Suggestions in case of errors 


Prevention of errors 


Name, role, value Throug 
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S. System test 


== |] == [em — 


Å user must be able to 


create a profile to 

use the system 

A user with a profile must be able 

to access the system with their 

email and password 

A user must be able to delete their Ås of today, the user is deleted 

profile with all relevant data they have 
registered. Optimally, the user can 
be deleted, and the 
supervision data can be 


kept anonymised 
Å user must be able to change 


their profile information 

Å user must be able to see the most 
recent trips that have been 
completed 

Å user must be able to 

access older trips and see details 
about the trip 

Å user must be able to 


create a new grazing group 
Å user must be able to 
create farms in the 

grazing group 


Å user must be able to add members 
to the group 


Å user must be able to accept an 
invitation to a grazing 

group 

A user must be able to 

access theirs 

grazing groups and see trips 
completed in the group 

Å user must be able to 

manage the group if the user is an 
administrator 


Å user must be able to start 


another inspection tour 
Å user must be able to download a 


map section for use without the 
internet 
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A user should be able to 

register flocks seen with the 
appropriate level of detail based 
on how much the user sees 

Å user must be able to 

record events on a surveillance 
trip such as sightings of predators 


Å user must be able to see an 
overview of the trip when 


the trip has been completed 


Å user must be able to 

create a profile to use the 

system 

Å user with a profile must be 

able to access the system with 

their email and password 

Å user must be able to delete As of today, the user is deleted 

their profile with all relevant data they 
have registered. Optimally, the 
user can be deleted, 
and the supervision 
data can be kept anonymised 


Å user must be able to change 
their profile information 


Å user must be able to see 


details of the trip after 
completing the trip 


Å user must be able to see 
the grazing quality in 
the grazing area in the map 


A user must be able to 


generate reports based on the 


grazing season in åa 
standardized format 


Not functional 


Faster to generate Measured 
reports than manual creation through comparison test 


Easier to find Measured by conversation 
grazing data/animal data about Ste with a domain expert 
your farm than without the system 
Fast to load data Under 1 second for 
loading data and 
displaying all pages in 
| the application 
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Follows current laws and 
regulations regarding 
privacy and GDPR 


Storage takes less than 2 
Data is stored securely and seconds locally and less than 10 
efficiently seconds to the cloud. 
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T. Questions and answers Final user test of the 
system 


Questions and answers, Mobile application 


The tasks below must be solved during testing of the Mobile Application: 
General Application Functionality: 

22. You have just accessed the application. Create a user and log in. 
Domain-Specific Application Functionality: 


23. You are a farmer who has just gained access to this system. You are a member of a grazing team 
that includes 3 farms and 5 supervisors. Create a group for the grazing team and add one of the 
farms and one of the supervisors. Give this person admin rights. 


24. You have been invited to the grazing group Oppdalsgruppa, Accept the invitation and find 
out how many farms are in the group. 

25. Find out how many predators were seen on the previous trip in the group. 

26. You are going out on å supervision round for the grazing team. Start a new inspection tour for 
the grazing team named Oppdalsgruppa. 

27. You wonder where the previous supervisor went for a walk, Show the previous walk that was 
completed in the map. 


Out 


28. Out on the inspection trip, you observe a flock of sheep. The sheep are quite far away and you have 
to use binoculars to see them. Register this flock while using binoculars to see them. (Instructed to 
register without looking at the phone and is read out 1 brown sheep and 3 brown lambs) 


2 


Ke 


Still out on the inspection tour, you observe a new herd quite close to you. Register a new flock of 2 
gray sheep with red markings, where one of them has a green tie and the other has a yellow tie. In 
addition, you see 3 gray lambs with red markings. 

30. The next herd you come across has 6 animals. The sheep are shown to the test subject. (1 Gray 
sheep with red tie, 1 Gray sheep with blue tie, 1 Brown sheep with yellow tie. 3 lambs. All with 

blue ear tags.) One lamb appears to have an injury to its left front leg. Register this. 


3 


— 


. On the trip you observe å dead animal. Register this find with photo evidence and 
then end the tour. 


32. When you return, you will upload the threat. Do this. 
Questions asked after the user test: 
Domain Expert: 


6. What did you think about the flow of the application? 
"Very good, it has all the functionality needed and it is clearly well thought out. I think it was 
easy to figure out, apart from the fact that I'm not quite used to the pattern with these round 
buttons. But it was good to find out how it worked.” 


7. Were there any buttons you weren't sure what they did? 
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"I struggled a little at once to see the difference between the round button on the home screen and 
the one on the grazing group page. But I see now that they have different icons and it makes 
sense that they do different things.” 

8. What did you think of the sheep registration flow? 
"I thought it was absolutely brilliant. I really like the fact that there are voice messages for 
the user in binocular mode and that you can bring up binocular mode or manual mode depending 
on how close you are to a herd." 

9. Do you have any other feedback? 
"I found the app to work very well and I found it very easy to navigate and find what I wanted 
to see." 


Test subject 1: 


1. What did you think about the flow of the application? 
"Very simple and straightforward to understand considering that it is the first time I have used 
the application." 

2. Were there any buttons you werent sure what they did? 
"| wasn't sure if it was necessary to download the map in order to start one 
trip." 

3. What did you think of the sheep registration flow? 
"The registration process was very simple and easy to understand. I had a little trouble figuring out 
which way to swipe the button to add or remove sheep in binoculars mode, but I figured it out 
after some testing. It was also a bit confusing that there was a separate field for the total 
number of sheep. I thought I had to fill this out first.” 


4. Do you have any other feedback? 
"It was a bit difficult to tell which element was active by looking at them in viewfinder mode. 
They could have been a little clearer.” 


Test subject 2: 


1. What did you think about the flow of the application? 
"I think the flow is good and I liked that I could always find important functionality on the round 
buttons that appeared on the different pages. I was a little unsure about the flow at the start of 
the trip since I didn't know if I had to download a map. But since it was the only button there, I 
thought I'd test it.” 


2. Were there any buttons you werent sure what they did? 
"I also thought it might have made sense to have å plus sign next to the map on the button on the 
front since I initially thought it was just a button to look at the map." 


3. What did you think of the sheep registration flow? 
"The registration flow worked really well and I liked being able to add and remove sheep very 
easily." 

4. Do you have any other feedback? 
"No, I thought the registration worked very well." 


Test subject 3: 


1. What did you think about the flow of the application? 
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"It was logical and I found what I needed to do. It was perhaps a bit difficult to find out where the 
trips ended up after I had completed them. I expected it to appear in the feed right away, but it 
had to be uploaded via profile first, 50 it was a little hard to see right away.” 


2. Were there any buttons you werent sure what they did? 
"I found that the cog at the top of the corner during a ride was not entirely intuitive to what was 
hidden behind there. Old tours I would expect to have a different icon although I don't know 
which one." 

3. What did you think of the sheep registration flow? 
"The registration flow worked very well, although I was åa bit confused by the total number of 
sheep in binoculars mode." 


4. Do you have any other feedback? 
"No, I thought it worked well and was easy to use." 


Questions and answers, Web application 


The tasks below must be solved during testing of the Web application: 
General Application Functionality: 

1. You have just accessed the application. Create a user and log in. 
Domain-Specific Application Functionality: 


2. Access the Oppdal group and identify how many trips have been completed this season. 


3. See data about the trip you completed. Check if the information you registered is correct 
correct. 


4. Inspect the photo you took of the dead animal. 
5. Find out which pasture quality is the most in Oppdal. 
6. Generate a report on the grazing season so far. 


Questions asked after the user test: 
Domain Expert: 


1. What did you think about the flow of the application? 
"Very easy to follow. I was a bit confused by where you could change pasture groups and that this 
was brought in straight away without me having to click any extra buttons." 


2. Were there any buttons you weren't sure what they did? 
"No, everything was very logical there." 
3. What did you think of the overview of a trip? 


"Very tidy and nice, got all the information I needed." 


4. Do you have any other feedback? 
*No, I thought this was a great application. And the fact that you can see pictures in the 


report is not even something that has occurred to me." 


Test subject 1: 
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1. What did you think about the flow of the application? 
"It was very easy to find out. Everything was available from the Dashboard.” 
2. Were there any buttons you werent sure what they did? 
"No, I thought everything was very easy to understand." 
3. What did you think of the overview of a trip? 
"Simple and straightforward overview, nothing to complain about." 
4. Do you have any other feedback? 
"No, not really." 


Test subject 2: 


1. What did you think about the flow of the application? 
"Very good structure, it was easy to get around. Nothing that was confusing in the structure.” 


2. Were there any buttons you weren't sure what they did? 
"No, thought it worked very well." 

3. What did you think of the overview of a trip? 
"Very good, it was fun to be able to see all the sheep you had registered and that a picture appeared 
on the event you registered in the application." 


4. Do you have any other feedback? 
"No." 


Test subject 3: 


1. What did you think about the flow of the application? 
"I thought it was fine, nothing confusing since you always have the menu available on 


the left-hand side. lt was also good that you could go back with the navigation button in the 
browser." 
2. Were there any buttons you weren't sure what they did? "no, 
everything was explained in text so I thought it was ok." 
5. What did you think of the overview of a trip? 
"It was very nice, I thought it was fun to see information about pasture quality coming out. 
Very interesting actually, and a bit of fun to see around the country. In addition, it was very nice to 
be able to click on the icons and get more information about the herd. Perhaps the herd in 
the side menu could be "highlighted" when it is selected or when you click on å herd in the map?" 


3. Do you have any other feedback? 
"No, thought it worked very well." 
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